Mail Archives: djgpp/2002/02/11/00:01:11
CBFalconer wrote:
>
> Eli Zaretskii wrote:
> >
> > On Sat, 9 Feb 2002, CBFalconer wrote:
> >
> > > > [1] c:\c\hashlib>gcc -c -gp -v malloc.c
> > ^^^
> > That should have been -pg, not -gp.
> >
> ... snip gcc -v output ...
> >
> > How did those "-gstabs+ -W -Wall" got into this this command? Did you
> > edit your specs file or something?
> >
> Through an alias I use.
>
... snip ...
> >
> > > Should I be using gstabs+, gstabs, or g?
> >
> > It doesn't matter, any -gSOMETHING switch will do for profiling.
> >
> > > I assume that if malloc is linked before the library search the
> > > library version will be omitted?
> >
> > Yes, of course: ld.exe is a one-pass linker.
> >
> > > All doubtless 2nd nature to you, but not to me. Hand holding
> > > needed :-)
> >
> > Don't give up, help is on its way ;-)
>
> Thanks. I think that covers it when I get back to trying things
> out.
Review - this is about investigating the poor performance of free
when handling a large number of items, in no particular order.
I can now compile with -pg and get a look (with gprof) at the
performance, in terms of functions, which simply confirms the
already known problem area as free (taking up 60% of run time).
dwpmi also shows up, but this is probably an effect, not a cause.
So the next step was to try to get detailed line information, as
follows:
(pasted as quote to avoid line wraps)
> [1] c:\c\hashlib>*gcc -c -pg -a -O2 -W -Wall -gstabs+ malloc.c
>
> [1] c:\c\hashlib>gcc -pg -a -o hshtestp hashtest.o cokusMT.o hashlib.o malloc.o
>
> [1] c:\c\hashlib>timerun hshtestp 4 10000
> Timer 3 on: 22:39:40
>
> Your program caused a divide overflow error.
> If the problem persists, contact your program vendor.
>
> [1] c:\c\hashlib>gcc -pg -o hshtestp hashtest.o cokusMT.o hashlib.o malloc.o
>
> [1] c:\c\hashlib>timerun hshtestp 4 10000
> Timer 3 on: 22:40:09
>
> Your program caused a divide overflow error.
> If the problem persists, contact your program vendor.
>
> [1] c:\c\hashlib>*gcc -c -pg -O2 -W -Wall -gstabs+ malloc.c
>
> [1] c:\c\hashlib>gcc -pg -o hshtestp hashtest.o cokusMT.o hashlib.o malloc.o
>
> [1] c:\c\hashlib>timerun hshtestp 4 10000
> Timer 3 on: 22:42:14
> HASHLIB test04
>
> New table, inserting 10000 values
> Status: Entries=10000, Deleted=0, Probes=48310, Misses=24413
>
> Walking returned 0
> 0 items were inserted 0 times
> 10000 items were inserted 1 times
> 0 items were inserted 2 times
> 0 items were inserted 3 times
> 0 items were inserted 4 times
> 0 items were inserted 5 times
> 0 items were inserted 6 times
> 0 items were inserted 7 times
> 0 items were inserted 8 times
> 0 items were inserted 9 or more times
>
> Timer 3 off: 22:42:17 Elapsed: 0:00:02.80
Once the -a option is used on malloc, the runtime blows up! Not
sure if the -a option was needed at link time, so I tried it both
ways.
NOTE: "*gcc" runs it raw, without the default "-W -Wall -ansi -
pedantic -O2 -gstabs+" options. timerun is an alias that starts
and stops a timer around the execution, it does not nest any
shells etc.
NOTE: The malloc source is straight out of the library source,
untouched.
Now what?
--
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT XXXXworldnet DOT att DOT net)
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:uce AT ftc DOT gov (for spambots to harvest)
- Raw text -