On Jan 8, 3:28 am, Volker Braun wrote:
> The notebook stuff hurts us twice in import times: First, many modules have
> their path added to sys.path making it longer. Second, the notebook stuff
> is actually imported in a plain commandline Sage session. And the modules
> are pretty slow, for exampl
On 2013-01-08 12:28, Volker Braun wrote:
> E.g. when you import
> foo then foo.{py, pyc} must be searched in the whole Python path.
Not to mention foo.so and the directory foo/
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group,
First of all, is there a problem? Sage starts in less than a second on my
desktop if caches are warm.
I didn't write the sage-forker, but I did write a module importer that
would get rid of all the failed open() attempts. Python does many
unnecessary filesystem operations when starting up. E.g
On 2013-01-07 23:49, William Stein wrote:
> I'm fine with removing it, since it doesn't do any good anyways.
OK, please review
http://trac.sagemath.org/sage_trac/ticket/13927
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, s
On Mon, Jan 7, 2013 at 11:32 PM, Jeroen Demeyer wrote:
> On 2013-01-07 23:54, Robert Bradshaw wrote:
>> I consider startup time to be one of our biggest bugs...
> I suggest to start with the notebook. Merging the flask notebook added
> about 0.5s to the startup time IIRC. Which is silly since th
On 2013-01-07 23:54, Robert Bradshaw wrote:
> I consider startup time to be one of our biggest bugs...
I suggest to start with the notebook. Merging the flask notebook added
about 0.5s to the startup time IIRC. Which is silly since the notebook
is something which really doesn't need to be importe
On 2013-01-07 23:54, Robert Bradshaw wrote:
> Hasn't this been discussed several times already?
Yes, but this is the first time William actually agrees with me :-)
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email t
On Mon, Jan 7, 2013 at 2:54 PM, Robert Bradshaw <
rober...@math.washington.edu> wrote:
> Hasn't this been discussed several times already? I consider startup time
> to be one of our biggest bugs... If we need to, lets bump it to 4 or even
> 10 seconds or something so at least we don't have egregio
Hasn't this been discussed several times already? I consider startup time
to be one of our biggest bugs... If we need to, lets bump it to 4 or even
10 seconds or something so at least we don't have egregious regressions. Or
replace it with something better (e.g. it only fails if the load is so
smal
On Mon, Jan 7, 2013 at 2:45 PM, Volker Braun wrote:
> I'm fine with removing the timing, but we should test somewhere that lazy
> imports are not accidentally imported during startup. Right now that file
> checks that numpy isn't imported. Though maybe it would be good to move it
> to a better-na
I'm fine with removing the timing, but we should test somewhere that lazy
imports are not accidentally imported during startup. Right now that file
checks that numpy isn't imported. Though maybe it would be good to move it
to a better-named file ;-)
On Monday, January 7, 2013 10:21:53 PM UTC,
11 matches
Mail list logo
