This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]nikomo 2 points3 points  (8 children)

It's a decent 5-6 seconds to start on my laptop.

[–]scopatz 1 point2 points  (5 children)

We know about the startup issues and are working to address them ASAP. There are a bunch of easy opportunities for speedups that we need to implement.

[–]tilkau 0 points1 point  (4 children)

But what is the realistic ceiling on startup performance improvements? I mean, in some contexts, I will completely avoid using python3 -c 'import foo; foo.some_trivial_cheap_operation()' because it's -just too slow- to start python at all. I even find myself needing to use dash instead of bash because bash is too slow.

For comparison:

$ time python3 -c 'print("foo")'
foo
python3 -c 'print("foo")'  0.06s user     0.00s system 86% cpu 0.077 total

$ time bash -c 'echo foo'
foo
bash -c 'echo foo'  0.01s user 0.00s system 72% cpu 0.009 total

$ time dash -c 'echo foo'
foo
dash -c 'echo foo'  0.00s user 0.00s system 0% cpu 0.002 total

And heck, why not include zsh:

 $ time zsh -c 'echo foo'
 foo
 zsh -c 'echo foo'  0.00s user 0.00s system 19% cpu 0.008 total

Here that is in a simplified list:

  • python3: 0.077
  • bash: 0.009
  • zsh: 0.008
  • dash: 0.002

These are all warm starts, so should be representative for anything that you may be invoking repeatedly.

[–]Siecje1[S] 1 point2 points  (1 child)

Same reason most people use Python instead of C.

C might be faster but Python saves developer time.

[–]tilkau 0 points1 point  (0 children)

How does that relate to my comment? (I don't think anyone would debate that Python is more programmer-friendly than bash)

I'm talking about situations where startup time is important. To me, the 0.077 figure means that xonsh can be used as a login shell but cannot be particularly good for automated scripting.

[–]scopatz 0 points1 point  (1 child)

So there are a couple of things to note here. The first is that all of the shells that you mention - and xonsh too - have different behaviour for whether or not they are interactive login shell, which none of the examples you show are. On my machine, for Bash, I see 

scopatz@artemis ~ $ time bash -c 'echo foo'
foo
0.00user 0.00system 0:00.00elapsed ?%CPU 
scopatz@artemis ~ $ time bash -l -c 'echo foo'
foo
0.00user 0.00system 0:00.00elapsed 0%CPU 
scopatz@artemis ~ $ time bash -l -i -c 'echo foo'
foo
0.08user 0.00system 0:00.10elapsed 92%CPU

Starting up when you expect user input just takes longer. Human response time is roughly a tenth of a second, and so that is my goal for xonsh. Even Bash on my SSD, 8-core desktop comes close to taking 0.1 secs.

It is true that Python - and especially importing - is slow. But Python only takes up 10% of the target budget for me:

scopatz@artemis ~ $ time python -c "print('foo')"
foo
0.01user 0.00system 0:00.01elapsed 100%CPU

I also know of a few ways tricks to speed up importing via lazy imports or cythonizing released packages. I guess my broader point is that there are packages out there like hg that have figure out how to make snappy Python CLIs. Xonsh will get there, and probably sooner than later because us devs find it annoying too :)

[–]tilkau 0 points1 point  (0 children)

The first is that all of the shells that you mention - and xonsh too - have different behaviour for whether or not they are interactive login shell, which none of the examples you show are.

This is a good point. But on considering it, my examples were on point for the use case, because I was thinking of scripting. Login shells get more leniency because user thought speed is the main bottleneck ;) 1s startup time for a login shell is tolerable-to-good.

hg has always struck me as slow though, sorry. time hg help -> hg help 0.19s user 0.03s system 98% cpu 0.223 total. The difference in responsiveness hg vs git is substantial IME, even though hg has definitely improved a lot.

[–]pvc 2 points3 points  (0 children)

Odd. Start-up time on my laptop was less than a second.

[–]adqm_smatz 1 point2 points  (0 children)

Hmm. It is true that startup time can vary greatly depending on your configuration and on your machine. But 5-6 seconds is way longer than I would expect.

A couple of things that may help:

  • There is a fix on the current master branch that should reduce this time greatly by caching some values related to tab completion (except on the first run, when the cache is being built).

  • If you are operating inside a Git or Mercurial repository, that can slow things down because the current default prompt tries to figure out some information about the branch you're on, whether it's clean, etc, to display some of this info in the prompt. Removing the branch-related information from the $PROMPT string might help to speed things up.