On 2010-Mar-03 21:01:54 +0100, Martin Rubey <martin.ru...@math.uni-hannover.de> wrote: >William Stein <wst...@gmail.com> writes: >> It's interesting that in all these threads nobody has mentioned "sage >> -startuptime". That's the command that reports on what modules are > >here goes:
Interesting but no smoking bullet. Looking only at the leaves, the longest startups are: sage.categories.enumerated_sets: 0.200 (sage.categories.finite_enumerated_sets) sage.libs.pari.gen: 0.156 (sage.rings.complex_double) matrix_mod2_dense: 0.145 (matrix_space) sage.libs.linbox.linbox: 0.110 (sage.matrix.matrix_integer_dense) sage.schemes.elliptic_curves.constructor: 0.100 (sage.databases.cremona) sage.quadratic_forms.genera.genus: 0.076 (sage.quadratic_forms.quadratic_form__genus) The problem seems to be more the length of the list, rather than the duration of any single member. Unfortunately, this means there isn't a simple solution. Parallelising the startup won't help if it's I/O limited (if anything, it will make it worse). About the only way I can see to improve startup speed would be to implement some form of lazy loading - during startup, Sage just loads a set of stub functions (from a very small number of physical files). When those stubs are called, they load the real function, replace themselves with it and then invoke it. In theory, this reduces bare startup time to roughly the time it takes python to start but I'm not sure how easy this would be to implement. -- Peter Jeremy
pgpNFoHKq5VGS.pgp
Description: PGP signature
