continued_fraction seems to leak memory

[Spencer Dembner]

When using continued_fraction to compute denominators of continued fraction convergents, I'm encountering what seems to be a memory leak. I'm running SageMath 9.0 on Windows 10 64-bit. If I run the following, 

for i in [2500000,..,2600000]:

    if i%1000 == 0:

        print(i);

        print(get_memory_usage());

    C = continued_fraction(sqrt(i));

    C.denominator(100);

then I see memory usage steadily climbing as I iterate through the loop. On the other hand, if I initialize sqrt(i) as an algebraic number, memory usage is essentially stable:

for i in [2500000,..,2600000]:

    if i%1000 == 0:

        print(i);

        print(get_memory_usage());

    if sqrt(i) not in QQ:

        K.<sqrti> = QuadraticField(i);

        C = continued_fraction(sqrti);

        C.denominator(100);

[Vincent Delecroix]

Thanks for your report.

Actually, it does not seem to have much to do with continued
fractions but rather with the symbolic ring

sage[4]: for i in [2500000,..,3000000]:
.......: if i%1000 == 0:
.......: print(i);
.......: print(get_memory_usage())
.......: _ = RIF(sqrt(i))

[Spencer Dembner]

Yup- what you wrote gives me the same result as far as climbing memory usage.

[Dave Morris]

Is this the issue that was reported in Trac #27185 (defect: sqrt memory leak)?

[Spencer Dembner]

It may be related, but I don't think it's exactly the same issue. For example, the following, involving no square root, still leaks memory:

for i in [1,..,20000]:

    if i%100 == 0:

        print(i);

        print(get_memory_usage());

    C = continued_fraction(pi^i);

    C.denominator(100);

[Dave Morris]

I think this last example is related to trac #27536 (conversion of mathematical constant such as pi to RDF leaks memory).  There is still a memory leak (but smaller, I think) if pi^i is replaced with pi, but I don't see a memory leak if pi^i is replaced with RDF.pi().  I also don't see a leak with RDF.pi()^i, but I quickly get a RecursionError ("maximum recursion depth exceeded").  I know almost nothing about memory leaks, but I just wanted to point out that I noticed some related issues that might possibly provide an explanation (and certainly seem to be relevant to a complete solution).

[Nils Bruin]

On Thursday, July 23, 2020 at 3:30:48 PM UTC-7, Dave Morris wrote:

I think this last example is related to trac #27536 (conversion of mathematical constant such as pi to RDF leaks memory).  There is still a memory leak (but smaller, I think) if pi^i is replaced with pi, but I don't see a memory leak if pi^i is replaced with RDF.pi().  I also don't see a leak with RDF.pi()^i, but I quickly get a RecursionError ("maximum recursion depth exceeded").  I know almost nothing about memory leaks, but I just wanted to point out that I noticed some related issues that might possibly provide an explanation (and certainly seem to be relevant to a complete solution).

That could well play a role too, but there are actually objects leaking on the python heap, which is not happening with  trac #27536.

[Nils Bruin]

On Thursday, July 23, 2020 at 2:39:09 PM UTC-7, Spencer Dembner wrote:

It may be related, but I don't think it's exactly the same issue. For example, the following, involving no square root, still leaks memory:

for i in [1,..,20000]:

    if i%100 == 0:

        print(i);

        print(get_memory_usage());

    C = continued_fraction(pi^i);

    C.denominator(100);

It's showing the same behaviour in that there are loads of sage.rings.real_mpfi.RealIntervalFieldElement elements piling up, so I think it's quite likely that the root cause is something similar to Trac #27185.