is there any downside to creating lots of class instances?

Question

I have lots of variables to keep track of in my game, and I'm wondering if there's any downside to creating lots of class instances:

event_1 = event(name, chance, [people])
event_2 = event(name, chance, [people])
...
events = [event_1, event_2]

instead of just creating a nested list?

events = [
    [name, chance, [people]],
    [name, chance, [people]],
    ...
    ]

other than the trading some instance names for ease of use in the case of classes, should I be worried about something like performance penalties or anything like that?

Edit: I mentioned the ease of use, what I'm wondering is: do classes in a list use more resources than a nested list or it's the other way around?

*Is* it a performance issue? Don't worry about it until it is. And… I'd go with a "hybrid solution" and use *many objects in a list*… — deceze, Jul 17 '19 at 06:54

score 2 · Accepted Answer · answered Jul 17 '19 at 06:56

My advice would be to first optimise for readability and maintainability of your code. Focus on performance only when it demonstrably becomes an issue. Once you know it's an issue, you'll be able to measure the system in its entirety, identify bottlenecks and fix them.

You may find that:

performance isn't an issue at all; or
it is an issue, but the bottleneck isn't at all where you thought it would be (from experience, this happens all the time).

With this in mind, I would favour the first approach over the second.

U13-Forward · Answer 2 · 2019-07-17T07:01:39.050

If your class doesn't do a lot of methods, just defines few instance variables, I would prefer to just use a nested list, an example class I mean:

class A:
    def __init__(self, a, b, c):
        self.a = a
        self.b = b
        self.c = c

If your class does do a lot of methods, I think it could be a good idea to use classes, an example class I mean:

class A:
    def __init__(self, a, b, c):
        self.a = a
        self.b = b
        self.c = c
     def f1(self):
         return [x / y for x, y in zip(self.a + self.b, self.c)]
     def f2(self):
         return [[*self.a, *self.b, *self.c, i + 1] for i in range(3)]
     def f3(self):
         for x, y in enumerate(self.a):
             if y > 3:
                 self.b[x] = y / 3
         return self.b
     ...

score 1 · Answer 3 · answered Jul 17 '19 at 07:16

This depends on what exactly constitutes downside to you. From performance perspective you should write for readability first, then measure, then optimize. But this is already written, so let's explore second major difference in those two styles.

If you write:

a = event(name, chance, [people])
b = event(name, chance, [people])
c = event(name, chance, [people])

then you create named instances. You can access them by name, which means, that they are easier to follow, when used and accessing them doesn't depend on order. On top of this accessing by a is slightly faster than list[a_index], although this isn't easy to measure.

On second hand writing:

list = [
    event(name, chance, [people]) # a
    event(name, chance, [people]) # b
    event(name, chance, [people]) # c
]

produes list. Now of course you can create named indexes for list and go like this list[index_for_a], but this is more cumbersome, requires way more code and this code is way more brittle (it's enough to modify order of the list once to blow everything up). On the other hand you get a list, which you can iterate in well defined order (you can iterate over members / local variables as well, but the order might chance arbitrary).

So those are major differences. What you pick is up to you, but personally i would go with first version, as naming is such a major boost to readability.

is there any downside to creating lots of class instances?

3 Answers3