|
From: | Dmitry Gutov |
Subject: | bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max |
Date: | Thu, 21 Sep 2023 20:54:30 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 |
On 21/09/2023 16:16, Eli Zaretskii wrote:
Date: Thu, 21 Sep 2023 15:20:57 +0300 Cc: Eli Zaretskii<eliz@gnu.org>, Stefan Kangas<stefankangas@gmail.com>, 66020@debbugs.gnu.org From: Dmitry Gutov<dmitry@gutov.dev> On 21/09/2023 05:36, Stefan Monnier wrote:make_process), although I had to use a value produced by make_uninit_string: apparently simply storing a char* field inside a managed structure creates problems for the GC and early segfaults. Anyway, the result was slightlyThat should depend on*where* you put that field. Basically, it has to come after: /* The thread a process is linked to, or nil for any thread. */ Lisp_Object thread; /* After this point, there are no Lisp_Objects. */ since all the words up to that point will be traced by the GC (and assumed to be Lisp_Object fields).Ah, thanks. That calls for another try. ...still no improvement, though no statistically significant slowdown either this time.Why did you expect a significant improvement?
No need to be surprised, I'm still growing intuition for what is fast and what is slow at this level of abstraction.
Allocating and freeing the same-size buffer in quick succession has got to be optimally handled by modern malloc implementations, so I wouldn't be surprised by what you discover. There should be no OS calls, just reuse of a buffer that was just recently free'd. The overhead exists, but is probably very small, so it is lost in the noise.
There are context switches after 'read_process_output' exits (control is returned to Emacs's event loop, the external process runs again, we wait on it with 'select'), it might not be there later, especially outside of the lab situation where we benchmark just single external process. So I don't know.
I'm not majorly concerned, of course, and wouldn't be at all, if not for the previously recorded minor degragation with larger buffers in the longer-running session (last table in https://debbugs.gnu.org/66020#10).
[Prev in Thread] | Current Thread | [Next in Thread] |