Obviously, editing time can be very different than start-up time, but it's easy
to benchmark start-up time and it's somewhat indicative. In the early 1990s
`emacs` with non-trivial `.emacs` configurations could take several to many
seconds just to start up and load a file while `vim` would start-up in the
blink of an eye (like `< 100ms`). These days, `vim` has become bloated (in
default configs) while `emacs` has gotten faster (especially with
`emacsclient`, and maybe even more so if this JIT compiler ever takes off). So,
$ utime vim -c quit nada
0.012548586 0 0 0.0%
$ utime emacs -q -nw --eval='(save-buffers-kill-terminal)'
0.017100606 0.01 0 58.5%
Run
or "both are pretty similar" (`12.5 ms` vs `17 ms`).
With `vim -u /dev/null -c quit` which is a little more fair since I had `-q` on
the `emacs` you see more like `1.8 ms`. (`vim --startuptime` doesn't show many
hot spots, but a lot of miscellanous loads.) However, with `emacsclient`, its
time goes down to a similar `2.9 ms`, only you get a fully loaded environment.
And the "busybox vi" start up is like 190 microseconds, but boy is that a
spartan environment - more analogous to vim of the early 90s.
All these times, though, are "too fast to notice", as is the case with most
everyday editing operations, unless there's some kind of loop. All probably
have "scaling holes" they could patch up with some significant re-engineering.
I mostly use `vim` and I've seen it grind to a halt with some really long lines
in binary files. Developer time generally matters a lot more, though that often
relies a lot on what one is "used to".
Anyway, I thought some numbers and command-lines that readers could try on
their own configs might add some objectivity. (Well, that `utime` thing is a
homebrew command of mine...Sorry. Needed the resolution.
[https://github.com/gsauthof/cgmemtime](https://github.com/gsauthof/cgmemtime)
will do `ms` resultion anyway.)
