Subject: bug#70231: closed (Re: bug#70231: Performance issue on sort with zero-sized pseudo files)

From: [email-masked] (GNU bug Tracking System)
Date: Sun, 07 Apr 2024 12:56:02 +0000

Your bug report

#70231: Performance issue on sort with zero-sized pseudo files

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
70231: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70231
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#70231: Performance issue on sort with zero-sized pseudo files
From: Pádraig Brady <[email-masked]>
To: Paul Eggert <[email-masked]>, Takashi Kusumi <[email-masked]>, [email-masked]
Date: Sun, 7 Apr 2024 13:55:40 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

On 06/04/2024 23:22, Paul Eggert wrote:
> On 2024-04-06 03:09, Pádraig Brady wrote:
>> I'll apply this.
> 
> Heh, I beat you to it by looking for similar errors elsewhere and
> applying the attached patches to fix the issues I found. None of them
> look like serious bugs.

Cool. I thought the sort(1) change worthy of a NEWS entry so pushed one.
Marking this as done.

>> BTW we should improve sort buffer handling in general
> 
> Oh yes.
> 
> PS. My current little task is to get i18n to work better with 'sort'.
> Among other things I want Unicode-style full case folding.

Excellent, that will help keep the related uniq(1) and join(1)
commands more aligned in their ordering.

cheers,
Pádraig

Subject: Performance issue on sort with zero-sized pseudo files
From: Takashi Kusumi <[email-masked]>
To: [email-masked]
Date: Sat, 6 Apr 2024 11:52:17 +0900
List-Id: <debbugs-submit.debbugs.gnu.org>

Hi,

I have found a performance issue with the sort command when used on
pseudo files with zero size. For instance, sorting `/proc/kallsyms`, as
demonstrated below, takes significantly longer than executing with
`cat`, generating numerous temporary files. I confirmed this issue on
v8.32 as well as on commit 8f3989d in the master branch.

   $ time cat /proc/kallsyms | sort > /dev/null
   real    0m0.954s
   user    0m0.873s
   sys     0m0.096s

   $ time sort /proc/kallsyms > /dev/null
   real    0m8.555s
   user    0m3.367s
   sys     0m5.064s

   $ strace -e trace=openat sort /proc/kallsyms 2>&1 > /dev/null \
     | grep /tmp/sort | head -100
   ...
   openat(AT_FDCWD, "/tmp/sortM6Y6Y1", ...
   openat(AT_FDCWD, "/tmp/sortPrHKMG", ...

   $ strace -e trace=openat -c sort /proc/kallsyms > /dev/null
   % time     seconds  usecs/call     calls    errors syscall
   ------ ----------- ----------- --------- --------- ----------------
   100.00    6.419777          19    333258         8 openat
   ------ ----------- ----------- --------- --------- ----------------
   100.00    6.419777          19    333258         8 total

It appears that the buffer size allocated for pseudo files with zero
size is insufficient, likely because it is based on their file size,
which is zero. As seen in the attached patch, I think using
`INPUT_FILE_SIZE_GUESS` to calculate the buffer size when the file size
is zero would resolve this issue.

Best regards,
Takashi Kusumi

From 9f759cc72014ab66da0e14318d4aa0c72e9311d9 Mon Sep 17 00:00:00 2001
From: Takashi Kusumi <[email-masked]>
Date: Fri, 5 Apr 2024 12:03:42 +0900
Subject: [PATCH] sort: fix performance issue on zero-sized pseudo files

Previously, an insufficient buffer size was chosen for zero-sized pseudo
files (e.g., /proc/kallsyms). Now, the buffer size is calculated using
INPUT_FILE_SIZE_GUESS when the file size is zero.
---
 src/sort.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/sort.c b/src/sort.c
index 329ed45dc..8d757da55 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -1538,7 +1538,7 @@ sort_buffer_size (FILE *const *fps, size_t nfps,
           != 0)
         sort_die (_("stat failed"), files[i]);
 
-      if (S_ISREG (st.st_mode))
+      if (S_ISREG (st.st_mode) && st.st_size != 0)
         file_size = st.st_size;
       else
         {
-- 
2.41.0