#15801: Categories over a base ring category
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: sage-6.2
Component: categories | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
public/categories/over-a-base- | 3a63847b3e313d2e4eb0261f156e7d0bb7bf7a9c
ring-category-15801 | Stopgaps:
Dependencies: #10963 |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Replying to [http://trac.sagemath.org/ticket/10963#comment:571 nbruin]:
> There are some performance and leaking issues with the proposed code
here. They
> have been mentioned before, but they got swamped in more theoretical
design
> discussions. Consider for instance with sage 6.2.beta4:
>
> ...
>
> As you can see, much slower execution and much leakier behaviour (even
without
> the patch this kind of stuff is very liable to leak but as you can see,
this
> patch makes it much worse). Note that we have to sort types by their
string
> representation, because for each of these `..._with_category` types, the
5000 instances are in fact unique types with identical print names. So the
memory load is even higher (types are fairly heavy data structures). As
you can see, categories are eternal (they get cached) and since they store
a reference to their base, they nail the base ring in memory too. We'll
have to merge this ticket together with a ticket that moves base ring
references out of the categories, since the constructions introduced in
this ticket make the problem urgent.
For the record, here is what I currently get on my machine:
With this ticket applied on top of #10963:
{{{
sage: import gc
sage: from collections import Counter
sage: before={id(c) for c in gc.get_objects()}
sage: %time for n in [1..5000]: x=(matrix(Integers(n),2,2,1))
CPU times: user 3.83 s, sys: 41.2 ms, total: 3.87 s
Wall time: 3.84 s
sage: sage: gc.collect()
17047
sage: sage: gc.collect()
864
sage: sage: after=[c for c in gc.get_objects() if id(c) not in before]
sage: sage: [c for c in Counter([str(type(a)) for a in after]).items() if
c[1] > 4000]
[]
}}}
Same, without systematic full category initialization for matrices:
{{{
CPU times: user 3.49 s, sys: 52.8 ms, total: 3.54 s
Wall time: 3.49 s
sage: sage: sage: sage: gc.collect()
18836
sage: sage: sage: sage: gc.collect()
1344
}}}
With vanilla 6.2.beta6 (no systematic full category initialization for
matrices):
{{{
CPU times: user 2.89 s, sys: 33.6 ms, total: 2.92 s
Wall time: 2.88 s
sage: sage: sage: gc.collect()
5032
sage: sage: sage: gc.collect()
704
}}}
Hence #15801 as is seems to be going a long way toward fixing this
issue. It's still non negligibly slower than develop on this very
tight loop (and apparently more objects get
allocated/deallocated). But in exchange we are back to systematic full
category initialization which I believe is much nicer to the user.
What do you think?
On to the elliptic curve benchmarks.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/15801#comment:14>
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.
For more options, visit https://groups.google.com/d/optout.
