Jason Grout wrote:
On 03/04/2010 02:35 AM, Robert Bradshaw wrote:
I often run things that take an order of magnitude less time to
run--e.g. I'm reading a paper and want to try out a quick example to get
a feel for something, or to factor (or even multiply) several digit
numbers. It also makes it prohibitive to be used as a (non-persistent)
web-service backend. I think partially it's a perception thing--one
could argue the same about a web page--why should I worry about it
taking 2 seconds to load/render if I'm going to spend an order of
magnitude more time reading it? Also, on that note, people's very first
exposure to Sage is waiting for it to start up--we don't want that to be
memorable :)
This last point is particularly noticeable when using Sage from the
notebook. A student will start up a Sage worksheet, type "1+1", and
then evaluate. Then the student has to wait the startup Sage time +
network transmission time + sometimes maxima startup time (depending on
the initial computation), and it feels like Sage is taking *way* too
long to answer a simple query.
Jason
Yes, I'd agree there. In fact, when I've tried this on my own Solaris machines,
where Sage is less well tested, I've often wondered if the server is not working.
Could a solution be to load all parts of Sage that are currently loaded, but to
load most of them in the background, after someone gets a Sage prompt?
If you could find the 10% of the code most frequently used by Sage users, then
load that before giving a prompt.
Then the other more obscure and less frequently used code silently loads. There
must be loads of Sage code that is used by only a small fraction of Sage users,
so it is less important if that takes longer to load.
Dave
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
