Ok, thanks again. Using the construction parameters is definitely an option and I will change it soon.
Am Mittwoch, 30. Oktober 2019 22:59:34 UTC+1 schrieb Nils Bruin: > > On Wednesday, October 30, 2019 at 2:31:37 PM UTC-7, Jonathan Kliem wrote: >> >> Basically, I can just do it like this. Now, if I understand it correctly: >> >> Face lattice as it is, should not be cached. Instead its probably fine to >> store the version with indices and convert on each call. Or the DiGraph. >> Just not the FiniteLatticePoset with labels that point to self. >> > > As a rule, a function that returns a UniqueRepresentation object should > NOT be a cached method. The UniqueRepresentation constructor is already > cached: it uses the construction parameters as a key into the cache, and > this is a global cache. > > What you can do is cache the construction keys themselves (provided they > are not UniqueRepresentation objects), so that you can call > UniqueRepresentation quickly. If that doesn't meet your performance > requirements then you shouldn't be using a UniqueRepresentation object. > > The reason why caching UniqueRepresentation objects VERY easily leads to > memory leaks is documented in many places, see e.g. > https://groups.google.com/forum/#!msg/sage-devel/q5uy_lI11jg/CB15fcRmE4cJ > (coincidentally also about FinitePoset). > > It is possible to cache a reference to a UniqueRepresentation object A on > an object B, but then you must make absolutely sure that there is NO > reference path from A to B. Generally, mathematical objects hold references > to the objects they are constructed from (possibly indirectly), so > generally this is not an option. This is a fundamental design weakness of > UniqueRepresentation that people get caught by again and again. Making > objects UniqueRepresentation is a very costly thing to do and therefore > very undesirable, even if it may seem like a nice property to have > superficially. It's just a requirement for participating in some of the > more advanced coercion discovery, because there "is" is used rather than > "==" for performance reasons. > > > > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/82afedba-ff0b-4e9f-bdf8-29c51c353929%40googlegroups.com.
