#13991: Mitigate speed regressions in symmetric function related code due to
#12313
---------------------------------+------------------------------------------
Reporter: nbruin | Owner: sage-combinat
Type: enhancement | Status: new
Priority: major | Milestone: sage-5.8
Component: combinatorics | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: | Merged in:
Dependencies: #13605 | Stopgaps:
---------------------------------+------------------------------------------
Comment (by SimonKing):
Replying to [comment:43 nbruin]:
> '''EDIT:''' Hm, this change didn't make a difference for me whatsoever.
However, running
> {{{
> sage: %time TestSuite(F).run()
> }}}
> as second time gives me ''much'' better performance and in `%prun` the
second time around, `weyl_group.py:937(action)` hardly shows up, so a
certain amount of caching is probably happening already. Note that
`WeylGroup` is a factory function that does some possibly rather expensive
preprocessing of its arguments. I guess if Simon would make his
`_Weyl_group_A` a `weakly_cached_function` (i'm sure someone experimented
with its implementation somewhere) we might be OK.
No, since this factory function is uncached. The cache lives in
`UniqueRepresentation` (from which the different flavours of Weyl groups
inherit), and they have a ''weak'' cache. Using another weak cache won't
help, I guess.
> In fact, I think that if we're finding that `WeylGroup` is too expensive
to create in typical usage scenarios (is this one?) we might want to
consider if it's possible to make their creation cheaper,
OK. This makes sense.
> That said, optimizations such as these should only be performed if we
find they are ''needed''. I wouldn't think that making a silly testsuite,
which may not reflect typical time-critical use of this code at all, run
faster as a reasonable optimization goal by itself.
OK, but who has typical use cases?
Something else.
I noticed that k_dual.py uses Partition, Partitions and
Partitions_all_bounded quite a lot---without storing their results in most
cases. Since their own cache is now weak, I wouldn't be surprised if here
is the reason for the slow down.
Since these partitions are repeatedly used in different methods, I think
they ''should'' be cached more strongly.
I see the following options:
- Use a strong cache for Partition(s) in general.
- Use a strong cache for Partition(s) only for those instances that were
created inside of the sage.combinat.sf.k_dual module. This would be
possible by applying the cached_function decorator to Partition(s):
`Partition = cached_function(Partition)` should be enough.
- Store a strong reference to the partitions that really were used in the
parent that was really using them. Hence, proceed as I suggested it for
Weyl groups.
What do you think?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13991#comment:45>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
