Re:The Emacs-28 release branch has been created
by michaelhoffman on Friday October 01, 2021 @09:58AM
(#28718492)
If you load a bunch of packages at startup that take several seconds to load that is as good a benchmark as any. I have this at the end of my init.el:
(run-with-idle-timer
3 nil
(lambda ()
(let ((inhibit-message t))
(message "Emacs ready in %s with %d garbage collections."
(format "%.2f seconds"
(float-time
(time-subtract after-init-time before-init-time)))
gcs-done))))
Re:The Emacs-28 release branch has been created
by taeric on Friday October 01, 2021 @10:03AM
(#28718565)
My startup had always been under a second. On a Mac, the command to get the path right is the longest pole. Remains so in native.
That said, I'll play with it some. Still looking for a broader benchmark, though.
Edit: Looks like I lied. Startup is about 2 seconds, but is mainly dominated by a network hit to refresh packages. (So, slower if I'm on a bad network... I should fix that.) Your script, though, is odd, as I can get to the Messages buffer and wait a second before I see that message show up. (Also, you can just eval (emacs-init-time))
Re:The Emacs-28 release branch has been created
by michaelhoffman on Friday October 01, 2021 @12:21PM
(#28720400)
I'm sure I got this code from someone else, was going to replace it with (emacs-init-time) myself but I suppose it's nice to only have the first two numerals after the decimal point which this code does and (emacs-init-time) doesn't.
Re:The Emacs-28 release branch has been created
by taeric on Friday October 01, 2021 @05:22PM
(#28723522)
Funny, coming back to this, if I recompile without native compilation and any other flags, I get faster startups. By upwards of 1 second. (So, from almost 2 seconds to almost 1 second.)
An emacs -q startup is roughly the same. And I maintain that many things feel snappier with the optimization flags.
Re:The Emacs-28 release branch has been created
by ashton314 on Friday October 01, 2021 @07:27PM
(#28724548)
Apropos of the path: have you tried setting your path in, say, `.zshenv`? When I started using that, I was able to shave off a significant amount of time because Emacs didn't have to fire up a full interactive shell to grab the env vars.
Re:The Emacs-28 release branch has been created
by taeric on Friday October 01, 2021 @10:08PM
(#28725343)
This is only on a Mac, right? I'll look into it, not a problem on my other machine.
Re:The Emacs-28 release branch has been created
by 5e92cb50239222b on Friday October 01, 2021 @09:59AM
(#28718504)
IME the only thing -march=native does is it makes it impossible to boot your system on an older microarchitecture (which is trivial with Linux otherwise — I really don't understand those who bring their bad Windows habits and do a reinstall when moving between systems).
Re:The Emacs-28 release branch has been created
by taeric on Friday October 01, 2021 @10:07AM
(#28718591)
I mean, it would do that. But, I also have never just moved the hard drive between machines. I've only owned two machines in the last decade. So, not even something I have had a lot of opportunity to do.
Back to the point, though, I'm assuming that libc dynamically does most of the optimizations that native enables?
What worries me, is that most of the feeling is just placebo. I know native is faster, but by how much? Are there any good benchmarks for measuring emacs speed?