On Aug 10, 2007, at 2:36 PM, David Harvey wrote: > On Fri, 10 Aug 2007, William Stein wrote: > >>> An automated test could then be written to pick up on things that >>> significantly slow down between releases. For example, maybe when >>> sage >>> -test is run, it can be supplied with timing data from a previous >>> run, >>> and produce warnings if anything is slower that it used to be. >> >> I think doing this, but with the doctests (as David Harvey I think >> suggested) >> might work better, since they are already written and are >> regularly maintained. > > Sorry, I don't think I meant to say that profiles should be done using > already existing doctest code. I think the kind of things we want to > profile are quite different from the kind of things we want to run > tests > on. For example I want to know how fast Integer creation is, or basic > arithmetic on GF(p) for small p, etc.
I think profiles should be done using already existing doctest, though not exclusively. If one runs sage -t, one might as well get some profiling information out of it (over a broad range of simple to very high-level functionality). I think it could save the benchmarking information to a benchmark file of some sort, and then one could post-process several runs over time at a later date to look for problems (or, once a history has been built up, even at each run). Of course some things (e.g. integer creation) may be something that one would have to test separately (or write a special function which then gets doctested). Timings of very large problems should probably not, however, be added to the doctests. - Robert --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
