LLMs defacto seem resource guzzlers, and are continuously overloading websites.

This is great. Overdue if you consider the values they espouse. Quite feasible for a compiler project to ignore the network effects of Github. Is their Discord usage next :-)

There is https://tauri.app/ coming up to let Electron app developers debloat their offerings.

Thanks. I’d not want to add a 3rd thing, RSS, into the mix, so following from Mastodon might be a workaround. Ideally, I would “follow” in Lemmy itself!

True, I am looking for “get threads boosted by this account”. If Mastodon did threads well, I would have stayed on it. I wouldn’t care for it at all if I could also “follow” accounts on Lemmy (and the accounts that matter were on Lemmy).

BTW, I liked the idea on emacs-devel about PGO/FDO experiments. And, with a short PGO Emacs session and compiling Emacs with that profile, I see almost all the responsiveness issues disappear. What is left are slow indent-region and slow file opening, which seem unrelated to UI responsiveness.

Are there automated UI test runners? Just a matter of recording macros, or even writing out elisp, I guess. Having targeted tests and using them for PGO/FDO to do Emacs releases seems useful.

My ₹1. It may depend on what you plan to write in it (for fun). The BEAM sounds great for long-running processes, but not as much for point tools; Erlang and co supposedly run slower than Python, which isn’t fast either.

My other ₹ ;-) if you stick to the BEAM: OCaml sort of runs on it, as there is the Caramel project to replicate it (https://caramel.run/). One of the Erlang creators also ported Prolog to the BEAM (erlog), as well as Lua (erlua) and Lisp (LFE). Elixir is probably great, as it is inspired by Ruby (I found Ruby very pleasant, other languages have so much semantic noise).

Freebie! The BEAM inspired an inspirational design for parallel programming, the Pony language. I am somewhat sad development slowed down, it is a Rust killer.

Thanks gor the numbers. They don’t make Emacs look unusable, so we could blame these darn cloud-provisioned VMs!

Thanks. True, verilog-mode is maybe 6 times slower than c+±mode. I should add some treesitter grammars and try c+±ts-mode etc.

File opening being slow must be a different aspect.

I don’t configure at all, Emacs is quite capable out of the box. But you are right that I should try with -Q. I tried and found things like, terminal versus GUI doesn’t make a difference, and disabling font-lock-mode makes it almost twice as fast (but I wouldn’t use Emacs that way).

I need a fast setup on the same hardware to compare against, but I don’t have it. This is the experience on VMs. I don’t know what is fast for people. I stated one of my observations that indenting a couple of thousand lines is slow. How fast is that for you, in a VM or on hardware?

I did some comparisions. The installation built without treesitter support is noticeably faster than the one built with treesitter support; even in the latter, I don’t have any treesitter grammars at all and no -ts-mode in use.

What hardware/VM and OS are you running on? What kind of development do you do in Emacs?

And, are you normalizing having to read the docs to have, for example, indent-region not be too slow?

I agree native-comp shouldn’t be necessary, since Emacs wasn’t this slow until maybe Emacs 25 and they keep improving the Elisp interpreter. And we probably can’t expect the speed from before the CPU vulnerability mitigations and from running on hardware from any software running in VMs nowadays.

What I see is much worse than that.

To be fair, Emacs handles large files better than Vim. But yes, Emacs is slower on typical tasks, to the extent that an Electron app like VSCode can feel more responsive. Some slowness could be acceptable due to Emacs’ flexibility, but getting slower over time messes up the experience.

On a lighter note. There are Git experts? ;-)