GNU bug report logs - #76103
[PATCH] New function 'process-output'

Previous Next

Full log

View this message in rfc822 format

From: Alvaro Ramirez <alvaro <at> xenodium.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, acorallo <at> gnu.org, 76103 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: bug#76103: [PATCH] New function 'process-output'
Date: Fri, 07 Feb 2025 23:19:17 +0000

Thanks Stefan

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Alvaro Ramirez <alvaro <at> xenodium.com> writes:
>
>> Thanks Eli.
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>> I'm not sure a 2.5 boost in performance
>>
>> (let ((before (benchmark-run 1000
>>                 (shell-command-to-string "seq 200")))
>>       (after (benchmark-run 1000
>>                (process-output "seq" "200"))))
>>   (/ (car before)
>>      (car after))) => 3.27
>>
>> Roughly a 3.27 gain, or should I calculate differently?
>
> I would benchmark this against `process-lines` instead, because 
> it
> doesn't spawn a shell.  On this macOS machine, I get 1.15 for 
> that
> benchmark.

Eli can correct me here, but he may have suggested 
shell-command-to-string as it provided a closer-looking interface.

When benchmarking against process-lines, the performance 
difference is indeed negligible.

>
>>> (on which platform, btw?) justifies yet another API.
>>
>> macOS. Need to grab a hold of a linux box to get equivalent
>> figure.
>
> AFAIU, the body of the proposed `process-output` could be 
> reduced to
>
>     (string-join (process-lines cmd) "\n")
>
> This makes me doubt if it's worth adding this new API.

Is there a slight chance re-joining lines with a "\n" does not 
preserve process output integrity?

If so, wouldn't users need to know process-lines internal details, 
thus inspect process-lines (elisp), process-lines-handling-status 
(elisp), line-beginning-position/line-end-position (.c), etc to 
ensure correct usage?

> To find arguments that would justify the addition, I'd take a 
> look at
> emacs.git to see which code we have that it would simplify.  I'd 
> also
> take a look at packages on GNU ELPA, NonGNU ELPA, and MELPA, to 
> find
> even more supporting evidence.

I had a quick look at emacs.git and GitHub (maybe where most of 
MELPA lives) and process-lines + string-join did not seem like a 
common pattern. Funnily, I found one in my code ;-) 
with-temp-buffer + call-process seems more prevalent.

While with-temp-buffer or process-lines options do the job just 
fine, this route may not be as discoverable as process-output for 
an elisp newcomer.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.