Avoid creating reference cycles on every frame

[nbraud]

While working on instrumenting the main loop (#244), I discovered that we create a reference cycles involving 7 cells on each frame, resulting in the GC actually needing to run (every 100 frames in the default configuration):

[<cell at 0x7fc417d84fa8: function object at 0x7fc417d9c8c8>, 
 <cell at 0x7fc417d84f78: And object at 0x7fc417d98fd0>,
 <function ParserElement.__mul__.<locals>.makeOptionalList at 0x7fc417d9c8c8>,
 (<cell at 0x7fc417d84fa8: function object at 0x7fc417d9c8c8>,
  <cell at 0x7fc417d84f78: And object at 0x7fc417d98fd0>)]

This seems to come from ppb itself (or a dependency), as hugs.py does not seem to create cycles (based on manual analysis of the ways its different datatypes interact).
Not creating reference-cycles means that well-behaved games could avoid running the GC entirely, resulting in lower jitter in the graphics output.

In any case, I believe this is quite low-priority, but I felt that it would be useful to create an issue to record/document the finding. Here is the patch I used to find which cells were involved in reference loops.

[pathunstrom]

What are the cells and parser elements?

[nbraud]

@pathunstrom I have no clue; that's the contents of the list gc.garbage (where the CPython GC puts unreachable objects when DEBUG_SAVEALL is set) but it doesn't tell me what allocated it.

[nbraud]

Nevermind, I just found out what was going on:

• the 7 cells/frame being in a reference loop were being allocated by the instrumentation code (or rather, by pandas when appending a new row to the dataframe);
• the adhoc instrumentation was printing the same garbage objects over and over: it clears them gc.garbage, making those objects unreachable... until the garbage collector finds that cycle again, collects it, and adds it to gc.garbage. 😿

Conclusion: ppb already avoids creating reference cycles continuously, which is good :)

[nbraud]

PS: I did fix the GC instrumentation while confirming was what was going on: 1421110