delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2002/07/19/19:50:57

Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3D389A5F.D9813428@phekda.freeserve.co.uk>
Date: Sat, 20 Jul 2002 00:01:51 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: DJGPP 2.04 performance & size
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1020617191254 DOT 11418A-100000 AT is>
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> On Mon, 17 Jun 2002 sandmann AT clio DOT rice DOT edu wrote:
> 
> > > In other words, does most of the difference come from globbing (which
> > > would point to `glob' and `findfirst') or from `stat' (which probably
> > > means we are paying for the symlink support)?
> >
> > The time for djecho seems to be the same for V2.03 and CVS, around
> > 4 seconds (with about 1 second accuracy ...)
> 
> That means the problem is probably in `stat'.  It would be interesting to
> profile two binaries of `ls', one from CVS, the other built with v2.03 or
> earlier, and see what portion does `stat' take.
[snip]

I finally got round to doing the tests. I built Fileutils 4.1 against DJGPP
2.03 (from the CVS v2_03_1 branch) and DJGPP CVS (from the CVS HEAD branch). I
built both of these versions with -gstabs+3 and -pg and gcc 3.1. In the case
of 2.03 a little hackery was required - I can send a diff, if anyone wants.
Basically I lifted small bits of HEAD and retrofitted them to 2.03.

I ran the following test in the src/ directory of each :

    time ./ls.exe -lR c:/temp/distmake

c:/temp/distmake contains build directories for all the packages I've
prepared. It's quite big, so it takes quite a long time to list. I ran the 'ls
-lR' a few times to ensure that the whole tree was cached. Here are the time
results, after filling the cache:

Fileutils 4.1 against 2.03:

real    0m50.700s
user    1m41.429s
sys     0m0.000s

Fileutils 4.1 against HEAD:

real    0m59.650s
user    1m59.341s
sys     0m0.000s

So HEAD doesn't look that much slower in terms of system calls, once all the
data is cached.

I've put the output of gprof for both runs here:

    http://www.phekda.freeserve.co.uk/richdawe/djgpp/workers/

The files are gzip'd.

I haven't had a chance to look at them in detail yet.

Bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019