Subject: Re: Optimization Opportunities 1 [long]
From: Sam TH (sam@uchicago.edu)
Date: Mon Feb 05 2001 - 07:58:54 CST
On Mon, Feb 05, 2001 at 02:10:39PM +0100, Mike Nordell wrote:
> Sam TH wrote:
> > 31084 for( x=0; x<hashheader.tblsize; x++ )
> > {
> > 31083 if( fread ( (char*)(hashtbl+x),
> > sizeof( struct dent)-sizeof( MASKTYPE ),
> > 1, fpHash)
>
> The fread() is a potentially very costly operation. Do "we" control the
> FILE*? If so, I'd set a larger buffer (setvbuf()) for this particular file
> and then see how it affects performance.
In what sense do you mean "own"? The file is the system dictionary
hash file. So we're probably not the owner of the file, in the Unix
file permissions sense. But we certainly own the pointer, and could
presumably read it in whatever manner we wanted. fpHash is declared
at the beginning of that function, and opened there as well.
>
> > 34873 for (j=0; j < EV_COUNT_EMS_NoShift; j++)
> > 139330 if (m_pebChar->m_peb[i][j])
> > 32906 {
> > // only check non-null entries
> > 32906 pEB = m_pebChar->m_peb[i][j];
>
> 1) What?! Are you really sure of these figures? If so, how is this possible?
> Would it display more correct figures if that foor-loop used curly-braces to
> enclose its scope, not just imply it? I have a hard time believing the "if"
> inside the loop gets executed _just over_ four times the loop executes it.
> 2) The "m_pebChar->m_peb[i][j]" could be aliased by "m_pebChar->m_peb[i]".
> This would possibly be much faster (depending on optimizer). For a debug
> build it will help, a lot. The whole expression should IMO also be aliased
> inside the "j" loop since it's used more than once.
>
Those sound like good ideas. Feel free to check them in, or just to
provide a patch if you want me to profile again.
> > 6981 for (j=0; j < EV_COUNT_EMS; j++)
> > 55797 if (m_pebNVK->m_peb[i][j])
>
> Yet again, how is this possible? Would curly braces correct these figures?
>
> > But the real question here is why we need to run these loops 60,000
> > times on start up. Ideas? Suggestions?
>
> After answers to my questions I can probably display both ideas and
> suggestions (actually, I don't only have access to Purify, I have Quantify
> also why I can provide quite accurate figures :-) (unfortunately only for
> win32) ).
>
I thought those numbers were weird too. But they are what gcov gave
me when I ran it. Maybe later I'll create a new run, and see if I
still get weird data. But it would be nice to see what you find.
> > 4) EV_UnixMenu::synthesizeMenu
>
> That one seems to be in need of emergency refactoring. IMO it was quite
> horrible.
>
> > This function, however, is likely to be very hard to optimize.
> > It's really long
>
> IMO the size of it is its largest error, _making_ it hard to optimize. Split
> into reasonable "units of work" and making (private!) member functions from
> those it would be a better starting point I think.
>
Yeah, sounds like an excellent idea. That code was mostly written in
early 1999, so it seems due for a little maintinence. Volutneers?
Could this be a POW?
> > 5) EV_EditBinding::getType [...] Any objections to inlining this?
>
> No. The type is already in place in the header file why it won't add
> compile-time dependencies nor add noticable compile time.
>
Can you commit that inling? My tree doesn't have Makefiles any more
:-)
> But I'd like to know two things.
> 1. Is this from a debug or releae build (if it even matters here, I don't
> know)?
non-debug. Also non-optimized, since I'm unsure of the relationship
between the optimizer and the profiler. Also, optimized builds start
too fast. :-)
> 2. This is coverage data. What does _performance_ data tells us? Is this
> really the places where it takes (real-) time? We have to differentiate
> between real-time and CPU-time. (if I/O takes a long time it's often not
> measurable CPU time but it can be really long real-time). Not that it
> matters to the user waiting for AW to start, but it's important if we're
> going to start to optimize.
Well, for starters, profiling tools for linux suck. What I have are
two programs, gprof and gcov. gprof generates a big listing of
functions, and how much time they take, and a big call graph. From
that I deduced that these four functions were taking up basically all
the time it took to start up. Then, I looked at the gcov coverage
data to determine where in those functions the bottlenecks were.
And as for real time, AbiWord really does start faster than emacs.
sam th
sam@uchicago.edu
http://www.abisource.com/~sam/
GnuPG Key:
http://www.abisource.com/~sam/key
This archive was generated by hypermail 2b25 : Mon Feb 05 2001 - 07:58:17 CST