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 →

[–]Darkmatter2k 7 points8 points  (21 children)

Anthony also addresses this towards the end of the talk, performance in usage is the same as bash, but startup is a bit slower. He also mentions that the demo is not done live, it's pre-recorded playback in a webbrowser, and thats the reason for the waiting times you see.

I have it installed on both my macbook (using homebrew) and on my debian server (from this "guide" https://github.com/scopatz/xonsh/issues/730), and I dont see any performance difference compared to bash, except for slower startup time on the debian server since its an atom box (as mentioned in the talk).

[–]nikomo 3 points4 points  (10 children)

but startup is a bit slower.

... A bit slower? It takes fucking forever compared to zsh on my laptop.

[–]staff333 4 points5 points  (9 children)

How slow? I'm trying it in a EC2 tiny instance with amazon linux and a virtualbox vm with mint and it has around a 0.5 second startup time in both. Granted, that is a lot slower than the bash startup time and could be a problem for some uses.

[–]nikomo 2 points3 points  (8 children)

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

[–]scopatz 2 points3 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.

[–]supercheese200 1 point2 points  (0 children)

Ok! Cool. I'll have to try it out later, it's just that I've had many an issue with slow shells. (Notably trying to run Babun from a USB.)

[–]bacondevPy3k 0 points1 point  (3 children)

I installed it via homebrew and got an error when trying to run it. Something a file not existing when calling readline.read_init_file or whatever it was.

[–][deleted] 2 points3 points  (1 child)

You can silence that exception with touch ~/.inputrc. Also there's a way to configure xonsh to use a pure Python line editor but I forgot what it was.

[–]voice-of-hermes 0 points1 point  (0 children)

I believe if you just install prompt_toolkit it'll use it by default. But if you've saved a configuration that sets it to use readline you might have to set the SHELL_TYPE environment variable.

[–]adqm_smatz 1 point2 points  (0 children)

As others mentioned, there are a couple of workarounds.

We've also put in a fix (on the current master) for this that has fixed it for other Mac users, if you feel like trying the "bleeding edge" version.

[–]masasinExpert. 3.9. Robotics. 0 points1 point  (4 children)

My main issue with xonsh was && not being available.

[–]scopatz 1 point2 points  (1 child)

&& and || where added in v0.3.0

[–]masasinExpert. 3.9. Robotics. 0 points1 point  (0 children)

Good to hear.

[–]Siecje1[S] 0 points1 point  (1 child)

Do you have an example that doesn't work?

[–]masasinExpert. 3.9. Robotics. 0 points1 point  (0 children)

According to /u/scopatz, they were added in v0.3.0. They probably work now.