users, I've been wanting to move away from JetBrains software to emacs for awhile now. I tried Doom emacs and it was very slow...suggestions were to turn off syntax highlighting, line count, and the treemacs package. It did help, but I still want those features. Is Doom just bloated? Would it be worth it to customize a base install of emacs to max out performance, or is emacs just not for me (meaning, I want all of these features)?

@tshrinivasan @kennethdodrill Emacs has gotten slower for me over time, 24.3 was the sweet spot of being fast enough and also being able to handle gigabyte-sized files.

Lots of Emacs packages work on older Emacs, so you could try 24.3 if you have time.

Another thing I should do is run a profiling build of Emacs for a few days (will be slow) and recompile Emacs with profiling data as optimization hints. For something that is used All The Time, seems worth it.
@wyatwerp @tshrinivasan @kennethdodrill unrelatedly wonder why profile based optimizations are black boxes.

it seems like we should be able to take data like this and run it in reverse, that is, have the compiler tell us what code paths *actually happened* so we can correct the original source code.
@icedquinn @kennethdodrill @tshrinivasan I didn't get what you are outlining. My low expectations for profile-based-optimization are that it puts code in the code segment together such that the icache is used more. Whatever else profile-based opti does, I am not at all sure how it helps in principle.
@wyatwerp @kennethdodrill @tshrinivasan depends on how serious the PBO is, but here we go

1. PBO inserts counters in various places like branches, counting
each time one of the two results is taken.

1a. This can also work in theory for more-than-two dispatches
assuming they are used properly. For example in Lisp where
you tend to have cond you have more than once branch point to

1a1. A cond is an if-else ladder; conditions are tested in
order but it's one "form." So its possible to list 5
related if-then-else without as much typing. If order of
tests does not matter (sometimes they do) then recording
which branch is taken most often is useful.

2. You then get a "profile" which says for each branch or dispatch
which path is taken most often. This allows the compiler to do
some trickery where if, say, the CPU has a bias towards wanting
to follow true paths it can re-write those branches so the more
common path is the true path (by say, inverting some conditions.)

3. But this information is lost to the guided profile files. They
are not deterministic. So builds of say Firefox start to require
data that is learned at test-running time.

3a. This is a problem for reproducible builds; since the profile
requires you to go do stuff, which could be indeterminate, as
say loading ten random web pages would not be reproducible.

4. This concept actually is more powerful than this. If you look at
GraalVM what it does is make a tree of programs and then it
counts things like which branches are most common. It even looks
at which types are most commonly used in some special case. It
learns which functions are used most often in certain paths.

5. That profile information in Graal is then fed back to the
compiler. So in say a dynamic language, it learns that some
specific types are the two most common. So it inserts
pre-dispatches for those two types and cuts out a lot of
overhead (it no longer has to do a full dispatch for the most
common case.)

6. But in all these systems you don't really get information back
to the programmer. You don't really get to explore the
optimizations to see which types are rarely instanced or which
code path is most common.

6a. I mean yes, there are some specific profilers and things. But
it tends to be a lot of overhead and task-specific. You can't
just do work in the program for a week and then come back and
go "ah, we need to make all these changes here and there."

basically optimizers are one-way black boxes; developers don't learn how to make better software because the optimizers don't communicate back what they actually did.
@kennethdodrill Elisp native compiler is on its way. People are aware that highlighting by regexps is a bad idea and this mechanism needs to be replaced. Jump in, experience various benefits of Lisp, support the development if you end up liking them. Performance will eventually catch up.

@kennethdodrill as someone who just started with vanilla emacs, and never bought into doom emacs (not that it's bad, but I don't need anything else, and if I do I find something already built in) ... why not try?

I always say this: Emacs come with SO many things out of the box, most folks needing something are usually new to it and not aware of the features or how to use them (manual can be cryptic).

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.