On Tuesday, August 12, 2014 7:29:01 AM UTC-7, Daniel Krenn wrote:
> (<type 'sage.rings.complex_interval.ComplexIntervalFieldElement'>, 2175)
> (<type 'sage.rings.real_mpfi.RealIntervalFieldElement'>, 8563)
Numbers of course depend on the context, but this doesn't look alarming.
You can probably check yourself if you expect the number of RIF and CIF
elements to be of this order. They certainly wouldn't keep anything in ECL
alive.
(<type 'sage.symbolic.expression.Expression'>, 28257)
>
This could be a large number (although expressions are recursive data
structures, so one complicated expression can cause a lot of them to
exist). Expressions could keep things in ecl alive, but there would have to
be EclObjects in memory for that and you're finding none. This suggests
that anything you're sending over to maxima gets sent there via the
strings-based interface.
> (<type 'tuple'>, 38713)
> (<type 'sage.rings.rational.Rational'>, 3555901)
>
that is a rather huge number. Are you keeping a large number of tuples with
rational numbers in memory somewhere (roughly 100 numbers per tuple on
average)? If not, then you may want to look where these are coming from.
It doesn't look like the results above help (but maybe I just interpret
> them wrongly)
>
Well, it excludes EclObject, so that is telling us that any "leaking" to
maxima would have to occur strings-based. The strings-based maxima
interface uses temporary symbols to tie translated results to in maxima. As
we know, generating symbols in common lisp almost always causes a memory
leak in that the symbol names get interned and never forgotten, this would
be the most likely reason to have leaking behaviour. We can find this out
by defining:
maxima_calculus(1) # make sure maxima_calculus is defined
from sage.libs.ecl import ecl_eval
def ecl_symbols():
return set(ecl_eval("""(let ((lst ())) (do-all-symbols (s lst) (push s
lst)) lst)"""))
Now let's do some tests to see if we're collecting any symbols:
A=ecl_symbols()
for i in range(10):
_= integrate(sin(x),1,10)
B = ecl_symbols()
print B.difference(A)
A= B
The above works fine: we get some symbols that do get defined initially,
but once they exist, no new symbols arise.
for i in range(10):
_= sin(x).simplify()
B = ecl_symbols()
print B.difference(A)
A= B
Here we see the culprit! "simplify" still uses the strings-based interface
and it is creating a new "temporary" symbol every time: $sage6, $sage7 etc.
This leaks.
To plug this, we should either try and reuse these symbols or dive into CL
to see if we can really unintern them (which is going to be the same
problem, because we'd have to know when it's safe to unintern, i.e., safe
to recycle.
Either that or someone sits down and finally removes the strings-based uses
from our maxima_lib interface.
So, my guess is that you're just making a lot of calls to maxima that end
up using the strings-based interface, rather than the binary interface, and
that the memory blow-up you're experiencing is the accumulation of
(unbound) `$sage...` symbols. This is certainly something that would always
happen, albeit slowly. However, you could of course be running into a
different leak as well, so it may be worth playing around with the above
yourself a bit.
--
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/d/optout.
