|optimization using profiling firstname.lastname@example.org (1998-11-12)|
|Re: optimization using profiling email@example.com (1998-11-15)|
|Re: optimization using profiling firstname.lastname@example.org (John Williams) (1998-11-15)|
|Re: optimization using profiling email@example.com (Joachim Durchholz) (1998-11-15)|
|From:||firstname.lastname@example.org (Mike Lee)|
|Date:||15 Nov 1998 13:29:04 -0500|
|Organization:||Ontek Corporation -- Laguna Hills, California|
In comp.compilers, email@example.com writes:
| How? What can be done after profiling that can't be done without it ?
| To get a real improvement, I guess I must run my application to cover
| ALL the possibilities (all branches in code), or I'll get worse
| performance, since the compiler will think that some code is never or
| almost never being executed, right?
My impression is that 90% of the value of profile feedback
optimization is in deciding which branch of an if-statement
or switch-statement to favor when making trade-offs in the
ordering of the object code. You mentioned it was a C++
compiler so it could be using the profile information for
inlining decisions also.
I agree with the moderator, you don't have to cover every
branch--so long as the hotspots get some profiling
attention, the optimizer should have enough information to
go on. If the hotspot isn't getting covered very well,
then it de facto isn't a hotspot after all.
Of course, read the profiler output yourself to draw your
attention to places in the code where algorithmic changes
may pay off more than micro-optimizations.
Return to the
Search the comp.compilers archives again.