-
Notifications
You must be signed in to change notification settings - Fork 181
Meataxe performance for reducible modules is often quite bad #6281
Description
In PR #6276 I made some things much faster for irreducible modules. But the example there trivially extends to reducible examples that are still far slower than they ought to be -- both when comparing to Magma or when considering trivial adhoc tests one could implement to make them faster. But of course we want generic (not adhoc) code, and a fix that hopefully doesn't make the existing fast path noticeably slower.
E.g.:
n:=10;; # increase this to make the effect even stronger
G:=GL(56,GF(25));;
H:=Subgroup(G, Concatenation(GeneratorsOfGroup(G),List([1..n],i->PseudoRandom(G))));;
dn:=g ->DirectSumGModule(NaturalGModule(g),NaturalGModule(g));;then
# fast
gap> MTX.IsIrreducible(dn(H)); time;
false
46
gap> MTX.Indecomposition(dn(G));; time;
84
# slow
gap> MTX.Indecomposition(dn(H));; time;
9130
gap> MTX.Indecomposition(dn(H));; time;
4785
gap> MTX.Indecomposition(dn(H));; time;
9190
No way it should take several seconds to compute that decomposition. The bottleneck is in SMTX.BasisModuleHomomorphisms and there in SpinHom.
I notice that we end up calling SMTX_AddEqns 1234 times; which amounts to 2*56=112 times as many "equation" it tries to produce, i.e., 138208 ; of those 137988 turn out to be redundant, so just 220 end up being relevant.
Now the problem increases with the number of generators; and here of course we have 10 redundant generators. Perhaps we can do a better job of discovering this?