Hi Georgi, On 2013-11-15, Georgi Guninski <gunin...@guninski.com> wrote: > Everyone knows sage has no bugs.
OMG, this means I lost my main occupation! > Appears to me the following program should use > O(1) memory. > > Watching memory usage in top(1), the proggie uses > 3GB ram in less than a minute and memory usage > increases constantly. There is supposed to be a slow increase, because the memory consumption of IntegerModRing(n**2) depends on the size of n, if I am not mistaken. However, it seems that you are right, there is a leak. Even with the git branch of trac ticket #15367 (that is supposed to fix some memory leak), I obtain: sage: def wief(): ....: n=2 ....: while n<10**20: ....: K=IntegerModRing(n**2) ....: if K(2)**(n-1)==1: ....: print n ....: print n, get_memory_usage() ....: n += 1 sage: get_memory_usage() 189.44140625 sage: import gc sage: _ = gc.collect() sage: len(gc.get_objects()) 94444 sage: wief() ... 60275 563.58203125 ^C--------------------------------------------------------------------------- KeyboardInterrupt Traceback (most recent call last) ... sage: _ = gc.collect() sage: len(gc.get_objects()) 3775157 > While I am still using sage, is there a workaround > for this ``feature''? If you do not do computations in your function "wief", but only create the IntegerModRing, then the memory consumption is rather steady. Hence, the fact that the memory consumption increases when doing computations indicates that Sage's coercion framework is responsible for the leak. Do you have a trac account? Then please create a ticket and put me as Cc. Otherwise I'll open a ticket myself. As a work-around, try this (I tested vanilla sage-5.13.beta2): sage: import gc sage: _ = gc.collect() sage: len(gc.get_objects()) 114412 sage: def wief(): ....: n=2 ....: while n<10**20: ....: K=IntegerModRing(n**2) ....: if K(2)**(n-1)==K.one(): ....: print n ....: print n, get_memory_usage() ....: n += 1 # <Ctrl-C> after more than 300,000 rounds sage: _ = gc.collect() sage: len(gc.get_objects()) 115199 The difference is as follows: If you compare an element of K with the integer "1", then Sage needs to compute a homomorphism from ZZ to K. This homomorphism is cached for later use. We try to make the caching that does not prevent unused rings from garbage collection. But it seems you've hit an example where Sage fails. With the new version of the function, the memory consumption first increases and then remains steady even for n>300,000. Best regards, Simon -- 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 sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/groups/opt_out.
