Cc: address@hidden, address@hidden
From: Daniel Colascione <address@hidden>
Date: Mon, 24 Oct 2016 02:47:03 -0700
$ time emacs --batch --eval t
0.027user 0.011system 0m0.048selapsed 79.66%CPU
Then I guess you will have to continue using unexec, and when that
alternative disappears, switch to some other editor.
I have lots of scripts that run using emacs -Q --batch; many are invoked
frequently in other scripts. Making each take 250ms instead of 27ms to
run will greatly increase the overall runtime of the high-level
operations.
Maybe --batch won't need to load all of the elc code, maybe we could
have a smaller batch.elc for that. Or maybe what Ken just wrote will
bring the load time below 100 ms, who knows.
IOW, I think we are arguing prematurely about something whose
performance we don't really understand, haven't measured yet, and
haven't even written yet. Doesn't sound like a good idea.
I don't see a need to regress performance here, since a
custom malloc will perform at least as well as the last glibc malloc
that supported unexec (since it could in principle be a literal copy of
that code), and we found the performance of that malloc acceptable. I
care _much_ more about runtime performance than I do about allocation
throughput once started.
The desire to drop unexec is not just because of malloc, it's because
advances in compilers, linkers, and system security make maintenance
of unexec harder and harder. For example, unexec is incompatible with
address sanitation and other similar security techniques. It also
regularly breaks when some new section is invented by the linker.
Etc. etc.
Therefore, we already decided to move towards eliminating unexec, and
the only issue we should discuss is how to do that. You are in fact
suggesting to overturn that decision, which I don't think people will
agree with.