[IPython-dev] slow startup due to script magic

Fernando Perez fperez.net at gmail.com
Sun Sep 23 16:56:06 EDT 2012

On Sat, Sep 22, 2012 at 6:19 PM, Jason Grout
<jason-sage at creativetrax.com> wrote:
> I suppose it would be pretty straightforward to add a nose test that
> would check the time to start a full kernel, right?

Yes, and we should build a way to track that over time on a
standardized machine.  I think the ideal quantity to track would be a
distribution of the ratio of starting ipython to starting python
itself, over a set of configurations (local linux/osx/windows,
machines with NFS filesystems, etc).  That's the ratio we don't want
diverging and which is meaningful, not really the absolute startup
time by itself (if python takes longer to start, there's nothing we
can do about that).

>>> Maybe we should keep it simple: rather than checking for the existence
>>> of each interpreter, just set a standard list. It would mean that
>>> users can tab complete e.g. %%pypy, even if they don't have pypy
>>> installed, but I don't think it will be too surprising if they try it
>>> and it fails.
>> We could also cache the search path and do it only on first usage,
>> rather than at IPython startup.  Else we can discuss moving this to an
>> optional extension...
> It's also less confusing to have a standard list that is always
> available.  Otherwise I have to try to guess why in the world I have
> %%ruby, but you don't.
> I'd say that %%ruby should invoke ruby with "/bin/env ruby" and leave it
> at that.  Why do we need to cache the path?

And what about windows?  Remember, IPython is 100% windows compatible,
so unix-y solutions aren't good enough for us.  But there may be a
similar solution for windows that we can rely on.

I think, however, that the idea was to only provide the %%foo scripts
for which interepreters were actually found, hence the (expensive)
checks on startup.  I'm leaning more towards:

- finding a valid way to make a 'env foo'-style call across platforms
- defining a hardcoded set of defaults we'll call that way
- simply giving a good error message if the user happens not to
actually have 'foo' installed on their system.

That would mean no caching involved, no expensive early searches, and
I think an acceptable user experience (you could argue an even better
one, in that they wouldn't have to wonder why %%ruby is an undefined
magic for them, instead simply knowing that %%ruby happens to call
ruby which they may need to install).

... aand as usual, while we talk, Min codes:



Further discussion should continue on the PR.



More information about the IPython-dev mailing list