Subject: Re: Optimization Opportunities 1 [long]
From: Mike Nordell (tamlin@algonet.se)
Date: Mon Feb 05 2001 - 07:10:39 CST
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.
> 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.
> 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) ).
> 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.
> 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.
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)?
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.
/Mike
This archive was generated by hypermail 2b25 : Mon Feb 05 2001 - 07:38:15 CST