Re: pdumper on Solaris 10

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 10 Dec 2024 14:39:54 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Maybe so, but why is such a long wait a problem?  GC _works_, and
> > works well.
> 
> Working on certain projects with lsp-mode is a miserable experience due
> to all the random pauses.

And the changes discussed in this sub-thread will make it
spectacularly faster?

> My perception of the past week or two using igc is that those pauses are
> much less jarring, if perceptible at all. I need more time to make a
> definitive judgment, though.

I was not talking about igc, and its advantages are clear to me.
That's not what this sub-thread is about.

> As code edition evolves and Emacs is put on more demanding tasks the
> limitations of GC become more obvious (and CPUs are not getting faster
> anymore).
> 
> Apart from that, I'm convinced that there is quite a bit of evolutionary
> pressure exerted by GC on the Elisp package ecosystem: something that
> works too slowly or is too bumpy does not atract users and die. Others
> may end devoting a lot of effort to optimize GC usage and when they
> finally work "well enough" (for some generous interpretation) most
> potential users already made their mind (flx.el is a paradigmatic case)
> or the package author simply stops working on it, sometimes without
> making the first release.
> 
> GC also diminishes the benefits of native-comp and other performance
> enhancements: no matter how fast you make your Elisp execution engine,
> the time taken by GC stablishes a hard limit.
> 
> But the "stop the world" mode of GC operation makes user experience
> quite worse even if the total time to perform a task is smaller.

All correct, but completely irrelevant to the issue at hand.