On Nov 30, 2006, at 8:50 PM, William Stein wrote:
>> IntegerModRing now has a method precompute_table() which will create >> a cached table of all ring elements which cuts down on the overhead a > > I've applied your patch and it does indeed speed things up. Thanks. > >> lot. Perhaps this should be automatically called in the constructor >> on rings of a certain size or less. > > Yes, it should be automatic. I did some tests, and making it > automatic > up to say 10^4 would certainly make sense. Then it costs at most 0.10 > seconds and 1MB RAM. I am starting to get really uneasy about all these cached ring elements. SAGE is going to start becoming a real memory hog if we keep doing this. I don't know where you get 1MB from. Is that 1MB per ring? (100 bytes per ring element?) If it's 1MB per ring, then I only have to be working modulo 500 or so integers simultaneously --- not at all a far- fetched situation --- before my typical desktop PC runs out of RAM. Which is of course ridiculous. SAGE must be able to run with < 64 GB RAM. I get the feeling that all these caching solutions are treating a symptom rather than the underlying problem. The underlying problem is that we don't have a decently fast way of creating Python objects in Pyrex. We got some of the way towards solving this problem at SAGE Days 2. Much of the work has been done for the Integer class. I hope that someone can put some effort into generalising and improving those efforts. I don't have the time right now to work on this. David --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
