Date: Thu, 30 Jan 2003 22:22:10 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp-workers AT delorie DOT com
Message-Id: <2561-Thu30Jan2003222210+0200-eliz@is.elta.co.il>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
In-reply-to: <3E39923A.3040907@mif.vu.lt> (message from Laurynas Biveinis on
	Thu, 30 Jan 2003 21:59:38 +0100)
Subject: Re: small solve_symlinks speedup
References:  <3E39923A DOT 3040907 AT mif DOT vu DOT lt>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Thu, 30 Jan 2003 21:59:38 +0100
> From: Laurynas Biveinis <laurynas DOT biveinis AT mif DOT vu DOT lt>
> 
> -----------------------------------------------
>                  0.00    0.02     305/24148       opendir [216]
>                  0.01    0.11    1801/24148       go32_exec <cycle 4> [55]
>                  0.01    0.12    2057/24148       stat [54]
>                  0.03    0.23    3914/24148       __chdir [99]
>                  0.04    0.32    5268/24148       __open [63]
>                  0.04    0.32    5354/24148       __access [76]
>                  0.04    0.33    5449/24148       __solve_dir_symlinks [103]
> [40]     0.3    0.17    1.44   24148         __solve_symlinks [40]
>                  0.11    0.97  114700/116604      __internal_readlink [53]
>                  0.11    0.15  114700/114700      advance [116]
>                  0.05    0.00  138848/3295731     strcpy [45]
>                  0.04    0.00   85143/3696692     strlen [41]
>                  0.02    0.00   24148/253548      strpbrk [135]
>                  0.00    0.00      57/32298       __djgpp_exception_processor <cycle 5> [52]
> -----------------------------------------------
> 
> Since most of the paths passed to __solve_symlinks are not
> symlinks, IMHO it is reasonable to make a shortcut and check
> that in advance at the very beginning of __solve_symlinks, thus
> saving a lot of __internal_readlink calls, which do disk I/O. It
> is impossible to catch all cases of non-symlinks cheaply due to
> /dev/ stuff, FSEXT and so on. So I came up with a patch below,
> which handles only simple cases of non-symlinks, nevertheless
> lots of them :) With this patch the callgraph above looks like this:
> 
> -----------------------------------------------
>                  0.00    0.02     305/24155       opendir [224]
>                  0.02    0.10    1801/24155       go32_exec <cycle 4> [54]
>                  0.03    0.12    2059/24155       stat [52]
>                  0.05    0.22    3914/24155       __chdir [88]
>                  0.07    0.30    5268/24155       __open [62]
>                  0.07    0.30    5355/24155       __access [82]
>                  0.08    0.31    5453/24155       __solve_dir_symlinks [97]
> [40]     0.3    0.33    1.35   24155         __solve_symlinks [40]
>                  0.05    1.00   86360/88266       __internal_readlink [53]
>                  0.11    0.10   62205/62205       advance [124]
>                  0.04    0.00   86360/3246148     strcpy [42]
>                  0.04    0.00   56026/3645530     strlen [27]
>                  0.01    0.00   13207/137617      strpbrk [186]
>                  0.00    0.00       1/35745       __djgpp_exception_processor <cycle 5> [41]
> -----------------------------------------------
> 
> So, is the patch below worth it?

Ahm, sorry, but where are the differences between these two graphs
that we are supposed to look at to answer your question?  To me, they
both look almost identical.

I do support any simple changes that minimize the number of files we
need to open and read.

> On a unrelated note, why does OpenBSD with Pentium MMX 200 Mhz and
> 16 MB RAM run configure scripts *much* faster than DJGPP on my desktop
> Pentium II 375 Mhz 192 RAM with W2K ?

Probably because pipes and `command` substitution goes through memory
instead of disk files.