5 ms·
Mercurial did a lot of work to reduce startup time via its demandimport module. https://www.mercurial-scm.org/repo/hg/file/tip/hgdemandimport/demandimportpy2.p
by jordigh 9y ago
Mercurial did a lot of work to reduce startup time via its demandimport module.
https://www.mercurial-scm.org/repo/hg/file/tip/hgdemandimport/demandimportpy2.py#l1 https://www.mercurial-scm.org/repo/hg/file/tip/hgdemandimpor...
Basically, it's a lazy loading of all imports. You can write `import foo` but it won't actually be imported until you do `foo.whatever()`.
It's a crutch, and it's true that hg still pays the overall startup cost of Python. However, even with "45 times slower than git", the situation is not so dire:
jordi@chloe:~$ time hg --version
Mercurial Distributed SCM (version 4.2.2)
(see https://mercurial-scm.org for more information)
Copyright (C) 2005-2017 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
real 0m0.096s
user 0m0.084s
sys 0m0.008s
jordi@chloe:~$ time git --version
git version 2.1.4
real 0m0.001s
user 0m0.000s
sys 0m0.000s
I really can barely perceive a difference between 0.096s and 0.001s. Since it really is a one-time startup cost, it's not like we can even say that this difference accumulates and that hg is overall 45 times slower than git.
Pierre-Yves also has an interesting talk about all of the tricks that have to go into hg in order to make it fast with Python. There's stuff like doing `method = object.method; method()` instead of doing `object.method()` over and over again to avoid paying the cost of method lookup and so forth:
https://2015.pycon.ca/en/schedule/53/ https://2015.pycon.ca/en/schedule/53/
- coldtea 9y ago>I really can barely perceive a difference between 0.096s and 0.001s. Since it really is a one-time startup cost, it's not like we can even say that this difference accumulates and that hg is overall 45 times slower than git. It's bad for many things -- like showing VCS status on your shell prompt or IDE status line, where you repeatedly start hg. 100ms+ delay every time you hit enter in your shell is noticeable (and that's just the version, now doing an actual "dirty" check takes more).
- Too 9y agoMercurial has something called command server[1], it's essentially a daemon listening on sockets to receive commands, designed just to avoid the cost of startup. I had to use it once in a CI system where we did invoke hg thousands of times for some reason i can't even remember. That can also be used for frequent polling like shell status. [1] https://www.mercurial-scm.org/wiki/CommandServer https://www.mercurial-scm.org/wiki/CommandServer
- ngoldbaum 9y agoIn fact I have hg locally aliased to chg and have not noticed any issues with it. Just much faster command completions and an actually usable shell that includes hg annotations.
- majewsky 9y agoPut this at the end of your bashrc: PS1="${PS1}\$(sleep 0.1)" Then tomorrow, we have another talk about how you can "barely perceive a difference" between 1 and 100 ms.
- jordigh 9y agoOkay. I just tried it right now and can't really notice after a few minutes. How can I reach you tomorrow to confirm? Do you have email? Email me at jordigh@octave.org and we can keep talking.
- d33 9y agoJust curious, are you used to SSHing from the other side of the earth?
- jordigh 9y agoNo, my ssh sessions usually feel instantaneous.
- majewsky 9y agoInteresting. I definitely noticed when I improved my prompt to render in 5 ms instead of 50 ms. There is no visible delay anymore between one command having executed and the prompt showing up and being ready to accept the next command. The shell feels much snappier as a result.
- jordigh 9y agoSo, after a day of using this, I can tell you that I kind of notice it if I'm paying attention, but most of the time I simply don't really care.