5 ms·

Mercurial's startup time is the reason why, for fish, I've implemented code to figure out if something might be a hg repo myself. Just calling `hg root` takes

by faho 8y ago

Mercurial's startup time is the reason why, for fish, I've implemented code to figure out if something might be a hg repo myself. Just calling `hg root` takes 200ms with hot cache. The equivalent code in fish-script takes about 3. Which enables us to turn on hg integration in the prompt by default. The equivalent `git rev-parse` call takes about 8ms.

anonymouz 8y ago
Somewhat tangentially, I noticed that fish performs quit badly in remote-mounted (sshfs) directories that are git repositories. I wonder if it would be possible to detect a remote mounted filesystem and turn off/tone down some of the round-trip heavy operations?
- justusw 8y ago
  I've gone through your problem myself countless times, and concluded that hitting ctrl+c to interrupt the status line every time it tries to render the current repository state is not very productive. My git status line uses timelimit (https://devel.ringlet.net/sysutils/timelimit/ https://devel.ringlet.net/sysutils/timelimit/) to automatically stop if any of the git status parts (dirty/staged/new files) take > 0.1 seconds to finish: https://github.com/justuswilhelm/pufferfish/blob/master/fish/functions/git_status.fish https://github.com/justuswilhelm/pufferfish/blob/master/fish...
majewsky 8y ago
Wow, that's quite a difference. But 8ms is still too slow for me. :) I implemented the Git recognition code myself in my own prompt using the minimal amount of FS operations [1], and it renders in 5 ms from start to finish, including a "git:branch-name/47d72fe825" display. [1] https://github.com/majewsky/gofu/blob/master/pkg/prompt/git.go https://github.com/majewsky/gofu/blob/master/pkg/prompt/git....
- avar 8y ago
  (I work on Git in my copious free time) One of the reasons git-rev-parse takes slightly longer than your implementation is that you just unconditionally truncate the SHA-1 to 10 bytes. E.g. run this on linux.git: git log --oneline --abbrev=10 --pretty=format:%h | grep -E -v '^.{10}$' | perl -pe 's/^(.{10}).*/$1/' You'll get 4 SHA-1s that are ambiguous at 10 characters, this problem will get a lot worse on bigger repositories. Which is not to say that there isn't a lot of room for improvement. The scope creep of initialization time is one of the things that tends to get worse over time without being noticed, but Git unlike (apparently) Python makes huge use of re-invoking itself as part of its own test suite (tens of thousands of times), so it's naturally kept in check somewhat. If you have this use-case I'd encourage you to start a thread on the Git mailing list about it.
ngoldbaum 8y ago
I implemented something similar for Xonsh.
- UnquietTinkerer 8y ago
  Ironically, xonsh itself suffers from a long startup time due to it's use of python. This is my primary (negative) experience with the issue in the linked article, and the reason why I stopped using xonsh.
quotemstr 8y ago
I put similar code in Emacs's vc-hg to get revision information straight form Mercurial's on-disk data structures instead of firing up an hg subprocess.
- faho 8y ago
  You mean actually reading dirstate[0] or just the branch/bookmark files? We also do the latter, but dirstate format isn't easily readable just with shell builtins (lots of fixed-length fields with NUL-byte padding, also we don't even have a `stat` builtin and the external program isn't a thing on macOS AFAIK), so we still fire up `hg status` for that - but only after we decide that there is a hg repo. [0]:https://www.mercurial-scm.org/wiki/DirState https://www.mercurial-scm.org/wiki/DirState
  - quotemstr 8y ago
    Yes, the dirstate. https://github.com/emacs-mirror/emacs/commit/de76a167dc09dc695a5acebabb7ab354a6bf556e#diff-46ea49f18ef6202e9436a621b2f176da https://github.com/emacs-mirror/emacs/commit/de76a167dc09dc6...

by faho 8y ago

anonymouz 8y ago

Somewhat tangentially, I noticed that fish performs quit badly in remote-mounted (sshfs) directories that are git repositories. I wonder if it would be possible to detect a remote mounted filesystem and turn off/tone down some of the round-trip heavy operations?

justusw 8y ago
I've gone through your problem myself countless times, and concluded that hitting ctrl+c to interrupt the status line every time it tries to render the current repository state is not very productive. My git status line uses timelimit (https://devel.ringlet.net/sysutils/timelimit/ https://devel.ringlet.net/sysutils/timelimit/) to automatically stop if any of the git status parts (dirty/staged/new files) take > 0.1 seconds to finish: https://github.com/justuswilhelm/pufferfish/blob/master/fish/functions/git_status.fish https://github.com/justuswilhelm/pufferfish/blob/master/fish...

majewsky 8y ago

Wow, that's quite a difference. But 8ms is still too slow for me. :) I implemented the Git recognition code myself in my own prompt using the minimal amount of FS operations [1], and it renders in 5 ms from start to finish, including a "git:branch-name/47d72fe825" display. [1] https://github.com/majewsky/gofu/blob/master/pkg/prompt/git.go https://github.com/majewsky/gofu/blob/master/pkg/prompt/git....

avar 8y ago
(I work on Git in my copious free time) One of the reasons git-rev-parse takes slightly longer than your implementation is that you just unconditionally truncate the SHA-1 to 10 bytes. E.g. run this on linux.git: git log --oneline --abbrev=10 --pretty=format:%h | grep -E -v '^.{10}$' | perl -pe 's/^(.{10}).*/$1/' You'll get 4 SHA-1s that are ambiguous at 10 characters, this problem will get a lot worse on bigger repositories. Which is not to say that there isn't a lot of room for improvement. The scope creep of initialization time is one of the things that tends to get worse over time without being noticed, but Git unlike (apparently) Python makes huge use of re-invoking itself as part of its own test suite (tens of thousands of times), so it's naturally kept in check somewhat. If you have this use-case I'd encourage you to start a thread on the Git mailing list about it.

ngoldbaum 8y ago

I implemented something similar for Xonsh.

UnquietTinkerer 8y ago
Ironically, xonsh itself suffers from a long startup time due to it's use of python. This is my primary (negative) experience with the issue in the linked article, and the reason why I stopped using xonsh.

quotemstr 8y ago

I put similar code in Emacs's vc-hg to get revision information straight form Mercurial's on-disk data structures instead of firing up an hg subprocess.

faho 8y ago
You mean actually reading dirstate[0] or just the branch/bookmark files? We also do the latter, but dirstate format isn't easily readable just with shell builtins (lots of fixed-length fields with NUL-byte padding, also we don't even have a `stat` builtin and the external program isn't a thing on macOS AFAIK), so we still fire up `hg status` for that - but only after we decide that there is a hg repo. [0]:https://www.mercurial-scm.org/wiki/DirState https://www.mercurial-scm.org/wiki/DirState
- quotemstr 8y ago
  Yes, the dirstate. https://github.com/emacs-mirror/emacs/commit/de76a167dc09dc695a5acebabb7ab354a6bf556e#diff-46ea49f18ef6202e9436a621b2f176da https://github.com/emacs-mirror/emacs/commit/de76a167dc09dc6...