Thanks for the examples. I've fixed the bug (see attached patch). The issue was that a certain function returned a huge negative exponent in the case of 0 as input, which meant computing 0 / (2**HUGE NUMBER), which took a long time and lots of memory.
On 5/12/07, Justin C. Walker <[EMAIL PROTECTED]> wrote: > > Yuck! Sorry for the sucky tables. I am resending with some columns > removed, in the hopes that it will be easier to read (the removed > columns don't contribute to the discussion). > > On May 12, 2007, at 11:04 , Michel wrote: > > > > > I found the problem I think. Consider: > > > > time RR(0).exact_rational() > > > > CPU times: user 0.81 s, sys: 0.39 s, total: 1.21 s > > Wall time: 1.23 > > > > 0.81s for such a trivial command is not normal. Also memory > > consumption > > goes up a lot, presumably causing an out of memory error on systems > > with little memory. > > > > I suspect there is a bug in mpfr_get_z_exp(value1,value2) > > when value2 is zero. > > Yow! I ran 'top' while SAGE worked on this. SAGE tells me (Mac OS > X, on a 2x2.7GHz G5 with 2.5 GB of memory) > > ========================================== > sage: time RR(0).exact_rational() > CPU times: user 0.80 s, sys: 0.77 s, total: 1.57 s > Wall time: 1.89 > 0 > ========================================== > > 'top' shows (with roughly a 1-second interval): > ========================================== > PID COMMAND %CPU TIME RPRVT RSHRD RSIZE VSIZE > 1671 python 0.0% 0:03.48 30.0M 13.2M 41.0M 231M > 1671 python 0.0% 0:03.48 30.0M 13.2M 41.0M 231M > 1671 python 20.8% 0:03.75 143M+ 13.3M+ 154M+ 359M+ > 1671 python 84.3% 0:04.93 286M+ 13.3M+ 375M+ 615M+ > 1671 python 8.8% 0:05.06 158M- 13.3M 169M- 359M- > 1671 python 0.0% 0:05.06 158M 13.3M 169M 359M > 1671 python 0.0% 0:05.06 158M 13.3M 169M 359M > ========================================== > > The 'VSIZE' is the total memory used by the process. 'RSIZE' is > resident (in-memory) usage. It seems that in this case, we could > have a leak (or there is a huge data structure to hold '0' :-}). > Note that the increase is all in "private" memory. I believe this > means that the memory is "malloc()"d and is not shared library code. > I can try to nail this down if it's of interest. > > A second run of the same command (10 minutes later) shows > ========================================== > sage: time RR(0).exact_rational() > CPU times: user 0.81 s, sys: 0.78 s, total: 1.59 s > Wall time: 2.91 > 0 > ========================================== > > and > > ========================================== > PID COMMAND %CPU TIME RPRVT RSHRD RSIZE VSIZE > 1671 python 0.0% 0:05.06 158M 13.3M 169M 359M > 1671 python 0.0% 0:05.06 158M 13.3M 169M 359M > 1671 python 0.0% 0:05.06 158M 13.3M 169M 359M > 1671 python 78.1% 0:06.07 420M+ 13.3M 431M+ 743M+ > 1671 python 21.5% 0:06.37 521M+ 13.3M 532M+ 743M > 1671 python 18.6% 0:06.65 286M- 13.3M 297M- 487M- > 1671 python 0.0% 0:06.65 286M 13.3M 297M 487M > 1671 python 0.0% 0:06.65 286M 13.3M 297M 487M > 1671 python 0.0% 0:06.65 286M 13.3M 297M 487M > ========================================== > > Justin > > -- > Justin C. Walker, Curmudgeon-At-Large > Institute for the Absorption of Federal Funds > -------- > Some people have a mental horizon of radius zero, and > call it their point of view. > -- David Hilbert > -------- > > > > > > > > -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
4412.patch
Description: Binary data
