On 8/10/07, David Harvey <[EMAIL PROTECTED]> wrote: > > On 8/10/07, Jack Schmidt <[EMAIL PROTECTED]> wrote: > >> > >> You might look at how GAP does this. Its tst directory contains > >> expected timings. One only compares relative times. GAP tests do not > >> fail on a pentium 75mhz, since GAP users employ a wide range of > >> hardware. Surely other software has similar features. > >> > > > > So you're suggesting something like: > > > > sage: 2 + 2 # takes at most 5s on a 2Ghz processor > > I don't think the timing data should be in the code. I want the profile > data to be updated over time, and it becomes hard if it's in the code. > > What I have in mind is more the following. We have some huge SAGE > script (or collection of scripts) that run a bunch of profiles, and > spit the results out to a file. The file is basically a list of (test > id, time) pairs. We run the profile on each SAGE release, and archive > the results. Then there should be a tool that compares the results of > two profiles, and draws attention to things that have slowed down > between versions. The file would also contain some header describing > the machine being run on.
That's exactly what I was thinking of when I wrote a reply at the same time as you. So that might be a good way to go. > I'm unclear what is meant by "relative times" mentioned above. Does > that mean (a) profile of function A relative to function B, or (b) > profile of function A in version X vs in version Y? Relative time makes me nervous -- shouldn't that not work... William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~----------~----~----~----~------~----~------~--~---
