Slim down the collector objects

[fingolfin]

A typical pcp collector currently can easily take up several hundred kilobytes of RAM. Creating lots of collectors (say, by creating lots of pcp groups) can thus quickly eat up large amounts of RAM, and also CPU time.

The reason for this is that the collector objects store lots of temporary data, including stacks used by the collection routine. So each collector has such a stack, which most of the time sit unused.

We should be able to remove most of these, and thus reduce the memory usage considerably.

Only caveat is that those collectors are also accessed by the GAP kernel code in src/objcftl.c (which really is there only for polycyclic). So any change needs to be coordinated between GAP and polycyclic.

[fingolfin]

So the plan would be to first modify the code in src/objcftl.c, as well as CollectPolycyclicGap in polycyclic, to note use PC_WORD_STACK, PC_WORD_EXPONENT_STACK, PC_SYLLABLE_STACK, PC_EXPONENT_STACK. Once a GAP version which does that has been released, a matching polycyclic release which stops setting PC_EXPONENT_STACK can be released (and which depends on that GAP version). And then in the next GAP version after that, PC_EXPONENT_STACK etc. can be removed.

[fingolfin]

I am also wondering how useful PC_GENERATORS and PC_INVERSES are.

[fingolfin]

The PC_*_STACK variables / entries are no longer used starting with GAP 4.10; also polycyclic was updated to only initialize them with older GAP versions. So we could make a release of polycyclic which requires GAP >= 4.10 and then get rid of PC_EXPONENT_STACK etc. inside of polycyclic, and then get rid of them in GAP 4.12, too.

[fingolfin]

To showcase the difference, this is what we get with the stacks inside the collector:

gap> MemoryUsage(HeisenbergPcpGroup(1));
102274

And this is what we get now, with latest GAP and polycyclic:

gap> MemoryUsage(HeisenbergPcpGroup(1));
3746

[fingolfin]

I'd say this is resolved.