Below is evidence (again) that the "leak" you are reporting is actually
caused by caching NumberField objects or related data. You can see that
when a calculation using a certain NumberField is repeated it does not
increase the size of the PARI heap, although the first time that the
calculation is done the size does increase. Moreover the second time that
the calculation is done it runs much faster. These two things indicate to
me that NumberField objects, or at least some of the computed data
regarding a particular number field, are being cached. This behavior is
surely intentional, which means that some caution should be used when
applying the the label "bug" to it. Some bugs are programming errors.
Others are features with unexpected side effects. I suspect this is the
latter case, and that a decision was made that the cost of memory used by
the caching is worth paying for the increase in speed that it allows.
(Incidentally, writing loops which create many number fields and then
immediately destroy each one is probably not the use case that the
designers of the Sage NumberField had in mind.)
Looking at the code in number_field.py I see that when a number field is
created a key is generated to uniquely identify that field. The
NumberField is not a class, but a function which accesses:
class NumberFieldFactory(UniqueFactory)
These things support my belief that aspects of number fields are being
cached and that the caching causes GENs on the PARI heap to be retained for
the life of the cache, but allows properties of a cached number field to be
looked up rather than recomputed.
The file number_field.py does not contain any attribution, so I do not know
who the author(s) may be. But the author(s) would be much able to explain
the rationale behind their design than I would. Maybe some of them read
this list ...
- Marc
sage: import cypari2
sage: pari = cypari2.Pari()
sage: pari.getheap()
[1, 9]
sage: for A in range(1, 10):
....: Kn = NumberField(x^2+A,'w')
....: m = Kn.class_group().order()
....:
sage: pari.getheap()
[21, 284]
sage: for A in range(1, 10):
....: Kn = NumberField(x^2+A,'w')
....: m = Kn.class_group().order()
....:
sage: pari.getheap()
[21, 284]
sage: def test(N):
....: for A in range(1, N):
....: Kn = NumberField(x^2+A,'w')
....: m = Kn.class_group().order()
....:
sage: pari.getheap()
[21, 284]
sage: %time test(100)
CPU times: user 217 ms, sys: 5.09 ms, total: 222 ms
Wall time: 222 ms
sage: pari.getheap()
[201, 4265]
sage: %time test(100)
CPU times: user 22.7 ms, sys: 1.48 ms, total: 24.2 ms
Wall time: 23 ms
sage: pari.getheap()
[201, 4265]
sage:
On Sunday, September 8, 2024 at 9:12:14 AM UTC-6 Marc Culler wrote:
> I agree that this is a bug. I do not think it is the same issue as the
> leak you reported involving elliptic curves. The reason I don't think so
> is that it is possible to compute class numbers with no memory leak using
> the PARI getno function in either cypari or cypari 2. There are many
> things that can cause the PARI heap to grow (and it happens in cypari2 with
> just ordinary vectors and matrices as discussed in cypari2 issue #112).
> One major cause of PARI heap GENs not getting freed is that those GENs are
> managed by Python Gen objects which are not being deallocated due to
> references being held by other Python objects. When a Python Gen is
> dealloc'ed it should free the PARI GEN which is it managing if that GEN is
> on the PARI heap. That was not happening with the t_VEC GEN describiing an
> elliptic curve, even though the Gen object was calling the PARI gunclone
> function because the gunclone function was not freeing the "lazy"
> components of that vector. (That has been fixed in cypari.)
>
> I think something else is causing Sage NumberField objects to leak memory
> (i.e. to not be deallocated) in your example. The fact that both issues
> involve growth of the PARI heap does not mean that both issues have the
> same cause. The statement that they "probably" have the same cause is not
> supported by any evidence and I do not believe that they do have the same
> cause.
>
> - Marc
>
> On Friday, September 6, 2024 at 3:26:55 AM UTC-6 Georgi Guninski wrote:
>
>> This is not complaint, it is an observation about bug of type memory
>> leak.
>> To leak about one GB, run the testcase `leaknf5` from the top of the
>> thread with argument N=3*10^4:
>>
>> #3*10^4 leaks: 1084.55 MB in 1m35.208s
>>
>
--
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/214258af-1c02-4dc4-b898-035420db5e17n%40googlegroups.com.
