|
From: | Daniel Colascione |
Subject: | Re: Skipping unexec via a big .elc file |
Date: | Mon, 24 Oct 2016 02:47:03 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 |
On 10/24/2016 01:41 AM, Eli Zaretskii wrote:
From: Andreas Schwab <address@hidden> Cc: Lars Ingebrigtsen <address@hidden>, address@hidden Date: Mon, 24 Oct 2016 10:24:26 +0200We are not talking about 1 sec, we are talking about less than half that time, potentially even 1/4th of a second.That's still a lot. $ time emacs --batch --eval t 0.027user 0.011system 0m0.048selapsed 79.66%CPUThen 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. 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.
[Prev in Thread] | Current Thread | [Next in Thread] |