On 5 January 2017 at 20:01, Nils Bruin <[email protected]> wrote: > On Thursday, January 5, 2017 at 11:27:05 AM UTC-8, John Cremona wrote: >> >> > I'm tempted to say: beware of memory leaks. Caching an extension on the >> > base >> > field would probably imply that both fields are now participating in a >> > reference cycle, anchored in the global UniqueRepresentation cache, so >> > they >> > would be uncollectable by the GC. >> >> I see. But in a situation where I was processing 500 elliptic curves >> each defined over a quintic field whose galois closure took 15 minutes >> to compute, I think you can understand why I added the cache decorator >> in my local development branch! > > > Yes, of course. For your purposes the field is basically globally defined > anyway, so you don't mind it it's immortal. If you'd be working with 500 > elliptic curves defined over *different* quintic number fields, you'd feel > differently.
In fact I have 6000 curves defined over a total of 34 quintic fields... > >> >> It is not so bad now I am using >> splitting field. By the way, this is at line 885 of >> >> https://github.com/sagemath/sage/blob/develop/src/sage/schemes/elliptic_curves/gal_reps_number_field.py, >> where replacing >> >> Kgal = K.galois_closure('b') >> >> by >> >> Kgal = K.defining_polynomial().splitting_field('b') >> >> had a rather dranmatic effect! >> > > Funnily enough, if you'd use a (weak) caching function GaloisClosure(K,'b') > for this instead, you'd be fine. Of course, if you use a weakvalue cache, > you'd run the risk that the closure gets garbage collected if you don't hold > a reference and a weakkey cache wouldn't help, because the closure would > keep K alive anyway. > > As often happens in these cases, if we want limited lifetime cached > information, it's up to you to keep a reference to keep the cache alive. And > if you have the reference anyway, why do you need to store it in a cache? > I'm not sure if there is a fits-all solution to these issues, but while the > "@cached_function" or "@cached_method" decorators are convenient ways to get > caching, it's often too crude to be suitable for inclusion in a > general-purpose distribution, where the same routines might end up in > tight-ish loops that could fill the memory with cached info. Caching is > hard ... Nils, this technical talk about caching should probably move to sage-devel. So while I have a couple of other ideas about that I'll not add them to his threa.d > > -- > You received this message because you are subscribed to the Google Groups > "sage-support" 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 https://groups.google.com/group/sage-support. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sage-support" 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 https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
