Re: [Gnu-arch-users] Slow inventories on large source trees

[Andrew Suffield]

On Thu, Apr 22, 2004 at 12:16:36PM -0700, Tom Lord wrote:
> 
>     > From: Aaron Bentley <address@hidden>
> 
>     > Andrew Suffield wrote:
>     > > On Wed, Apr 21, 2004 at 12:48:55PM -0400, Aaron Bentley wrote:
> 
>     > >>According to gprof, it's spending 78% of its time doing regex 
> matching 
>     > >>in filename_matches.  The lion's share of that is in mem_set0, but 
>     > >>you've got to consider that it's doing 9 hundred thousand calls.
> 
>     > > I would be interested to know how memset(..., 0, ...) behaves (#define
>     > > mem_set0 to that), since at least in theory, mem_set0 is between 10
>     > > and 100 times slower than memset() on an athlon (and around 10 times
>     > > on a pentium 3 or 4).
> 
>     > tla inventory is about 50% faster when memset is substituted in the 
>     > regexp functions:
> 
>     > real    0m4.192s
>     > user    0m4.110s
>     > sys     0m0.080s
> 
> Is GCC inlining memset or are you getting a libc version?   Either way
> optimization.

glibc provides magic functions that are carefully designed so that gcc
can inline and optimise them extremely efficiently. In addition, the
"naive student" loops used by hackerlab are notoriously bad on modern
processors for a variety of reasons, especially athlons.

(That said, in this particular instance the call will be turned into a
gcc builtin by glibc, but that's beside the point)

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature