[GAP Forum] Stop GAP from storing group properties

Marc Keilberg keilberg at usc.edu
Sun May 9 03:28:17 BST 2021


Curiously, the memory consumption explosion still happens when creating
copies via generators.  Because before calling Pcgs there is no "Pcgs"
component to the group, but afterwards there is.  And this is, apparently,
a significantly larger amount of data.  MemoryUsage may report a
consumption of about 9k before calling Pcgs, but reports over 157k
afterwards.

This is the output of NamesOfComponent immediately after constructing the
groups:
[ "Size", "OneImmutable", "Order", "GeneratorsOfMagmaWithInverses",
  "PrimePGroup", "FamilyPcgs", "HomePcgs", "GeneralizedPcgs", "NuclearRank",
  "MultiplicatorRank", "ANUPQIdentity", "ANUPQAutomorphisms" ]

Using the function GeneralizedPcgs or simply GeneratorsOfGroup instead of
Pcgs, or applying AttributeValueNotSet in conjunction with Pcgs, fixes that
problem predictably enough.

However, there's still a difference in memory consumption of about 200
bytes. In all variations using functions to get the generators that I've
tested the original group always picks up a new component of
TrivialSubmagmaWithOne, aka the trivial subgroup, which evidently consumes
about 200 bytes.  Indeed, it seems this new component appears even when
trying to directly access stored components: using G!.GeneralizedPcgs still
computes the trivial subgroup and consumes the same extra 200 bytes or so.

Now an inflation of 200 bytes or so per group is sufficient for immediate
purposes to keep things within my system capabilities, and probably
future ones as well (it's all of 10MB extra over some 50k groups).  But is
there any way to avoid it?  And any particular reason that even direct
access to components is causing more components to be computed and stored?

Thanks,
Marc


On Sat, May 8, 2021 at 1:49 PM Hulpke,Alexander <
Alexander.Hulpke at colostate.edu> wrote:

> Dear Forum, Dear Marc Keilberg,
>
> > I've been looking to sift through a particular family of a few
> ten-thousand
> > groups, which are not in any of the current libraries, to see if they
> have
> > certain properties.  While it's relatively easy to construct the entire
> > family of groups via the anupq package, and the test I run on them is
> > relatively quick (a second or two per group on my computer), I run into
> > serious memory consumption issues when I go to start testing them all
> (with
> > a function specifically written to perform the test in question).  While
> > the list of groups I want only takes up a few gigabytes, and each
> iteration
> > of the testing function should be consuming a small fraction of that
> before
> > it completes, my total memory consumption constantly ticks up as I run
> > through the list, ultimately consuming well more memory than the list of
> > groups itself.
>
> There are tools (such as `AttributeValueNotSet` that aim to do this, but
> it is still possible that attributes that get called in the course of the
> calculation still get stored.
>
> What I have therefore done in such situations is to simply delete the
> whole group after having used it. This can happen in one of two ways
> (assuming L is your list of groups):
>
> a) You do not need the groups, only data obtained from them, or one
> counterexample:
>
> for i in [1..Length(L)] do
>   G:=L[i];
>   # now do the test
>   ...
>   Unbind(L[i]);  # so the group is gone as soon as the next iteration
> assignes G.
> od;
>
> A more subtle way (with keeping the list) is work on a new group G that is
> defined the same way (but is a different object.
> If you have permutation groups, you can do this as:
>
> G:=Group(GeneratorsOfGroup(L[i]));
> SetSize(G,Size(L[i])); # speeds things up if large
>
> but I suspect you have PcGroups. For these, it is probably best to make a
> *new* pc group with the same generators, so that there is nothing stored
> through attributes of the pcgs. That is, you use:
>
> G:=GroupByPcgs(Pcgs(L[i]));
>
> You will get a formally different group with same multiplication rules,
> and you can discard it once you are done.
>
> All the best,
>
>  Alexander Hulpke
>
>
>


More information about the Forum mailing list