On 19-09-03 11:31:32, Nils Bruin wrote:
>
>
> On Tuesday, September 3, 2019 at 2:43:27 AM UTC-7, Jori Mäntysalo (TAU)
> wrote:
> >
> > There is also at least %mprun magic. Googling that will give you some
> > examples.
> >
> > Looking at the memory footprint of the entire process (as a function of
> time) gives some indication of memory use of a certain implementation of an
> algorithm, but there are many factors that influence it. CPython probably
> has a slight preference for reusing (freed/reclaimed) memory over
> requesting new memory from the OS, but there is not an actual guarantee.
> And CPython might be seriously lax in reclaiming memory, or it might be
> prevented by a memory leak in sage that is not due to the implementation of
> the algorithm. So you can take results like that only as an indication and
> not as authoritative. Determining memory usage of an algorithm in the
> mathematical sense probably needs code analysis.
>
> (that said, memory claimed from the OS definitely gives an UPPER BOUND on
> the memory usage of a certain algorithm; for obvious reasons)
>
Well, one of the algorithms stores
sum {l^e} {\binom{n}{e}}
with l being the number of elements of the field
which gets big quite fast
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-support/66674d87-2f64-4da1-89f9-009b2898d3a4%40googlegroups.com.
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/sage-support/20190903195428.zge4htnopcsadfko%40deathbolt.927589452.space.
