emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Skipping unexec via a big .elc file


From: Daniel Colascione
Subject: Re: Skipping unexec via a big .elc file
Date: Mon, 24 Oct 2016 09:17:14 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

On 10/24/2016 08:58 AM, Eli Zaretskii wrote:
Cc: address@hidden
From: Daniel Colascione <address@hidden>
Date: Mon, 24 Oct 2016 07:45:17 -0700

In any case, I don't think it's right to throw out this idea without
trying very hard to make it work, because the benefits are so clear.

I'm worried that it'll be deemed to "work" at a level of performance
much worse than what we have today.

Why would you worry that it'll be accepted then more easily than it's
accepted now?  The same arguments will be voiced in the future if the
solution's performance turns out to be insufficient.

I don't see the unexec maintenance situation being desperate enough
that we need to accept a big performance loss.

I very much disagree with this: the unexec maintenance situation is
actually so fragile that it could break at any moment, in the sense
that we could very easily get into having no people on board who know
enough about unexec to solve the next problem that will break it.  The
number of people who do know gets smaller and smaller with each year.
That is not healthy at all for the future of the project.

In both this discussion and the one about insdel, you've expressed the sentiment that we need to optimize for a world in which very few people have time to maintain Emacs internals. I have a more optimistic view: people are generally good at figuring things out, and if learning about unexec or other esoteric facilities is that prevents a developer from porting Emacs to a new platform or fixing an important bug, that developer will put time into learning about these mechanisms.

That is, we *could* get into a situation where "no people on board [] know enough about unexec to solve the next problem", but that situation will resolve itself when people learn about unexec.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]