GNU bug report logs - #64735
29.0.92; find invocations are ~15x slower because of ignores

Previous Next

Full log

Message #443 received at 64735 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, sbaugh <at> janestreet.com, yantar92 <at> posteo.net,
 64735 <at> debbugs.gnu.org
Subject: Re: bug#64735: 29.0.92; find invocations are ~15x slower because of
 ignores
Date: Wed, 26 Jul 2023 05:35:13 +0300

On 26/07/2023 05:28, Eli Zaretskii wrote:
>> Date: Wed, 26 Jul 2023 04:56:20 +0300
>> Cc:luangruo <at> yahoo.com,sbaugh <at> janestreet.com,yantar92 <at> posteo.net,
>>   64735 <at> debbugs.gnu.org
>> From: Dmitry Gutov<dmitry <at> gutov.dev>
>>
>> Your other idea (spending time in text conversion) also sounds
>> plausible, but I don't know whether this much overhead can be explained
>> by it. And don't we have to convert any process's output to our internal
>> encoding anyway, on any platform?
> We do, but you-all probably run your tests on a system where the
> external encoding is UTF-8, right?  That is much faster.

I do. I suppose that transcoding can/uses the short-circuit approach, 
avoiding extra copying when the memory representations match.

It should be possible to measure the encoding's overhead by checking how 
big the output is, testing our code on a smaller string, and 
multiplying. Or, more roughly, by piping it to "iconv -f Windows-1251 -t 
UTF-8" and measuring how long it will take to finish (if our encoding 
takes longer, that could point to an optimization opportunity as well).

Previous Next

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