Re: Puzzling performance difference after refactor
Re: Puzzling performance difference after refactor
- Subject: Re: Puzzling performance difference after refactor
- From: Bill Monk <email@hidden>
- Date: Tue, 4 Jul 2006 00:10:35 -0500
On Jul 1, 2006, at 2:05 PM, Steve Checkoway wrote:
Without knowing what function B is nor how often it is called, one
thing comes to mind. Is B a small function that gets called many
times? If so, it's possible that when it was in the same file as A,
it was being inlined and if the function itself is short, it probably
doesn't take much time to execute. Without being able to inline the
function, you could be spending a large amount of time in the
function prologue/epilogue relative to the time spent in the function
body itself.
Indeed, function B is fairly small, gets called several times within
the hot loop, and was moved into a separate file of utility routines
that are used throughout the app.
Have you tried moving the definition of B into the same file as A and
declaring it static? If so, how does that affect the run time?
Thanks. Doing that restored a large measure of the lost speed
(actually, since function "B" is used in many files now, couldn't
easily declare it static, so just copied it into the hot loop's file
with a unique name and a static declaration). This caused B to
completely drop out of Shark's list of hotspots.
On Jul 1, 2006, at 2:05 PM, John Lunt wrote:
I believe its more general than that. (Almost) all optimization in
GCC 4.0 is done at a file level.
Interesting.
I forget to mention earlier that a CW 10 debugging build of the multi-
file version is just as fast as a single-file XCode release build (as
is an old classic version built with MPW pascal version). By breaking
up the large file, to avoid Xcode's 30-90 second delay each time it
was opened, I unwittingly turned off the gcc optimizations that were
making the app fast.
There has been some progress in 4.1 and 4.2 towards whole program
optimization, but this can easily get you back to your original
situation of the compile taking a large amount of resources.
Having said that, I think Steve's suggestion of the inlining is the
most likely culprit.
Makes sense. I see now from gcc docs that will inline functions even
if they aren't actually declared as inline, if its analysis is that
it will help. This must have been what was happening with the single-
file version.
On Fri, 30 Jun 2006, David Dunham wrote:
I assume you can work around this by
#include "separateFile1.c"
#include "separateFile2.c"
etc. to get everything into the same compile, yet have smaller files
to edit.
Yes, thanks, that works fine. I knew that was possible, of course,
but don't think I've ever before had a real-world reason to include
multiple .c files in another .c file, and it just didn't come to mind...
Anyway, I simply duplicated the target, showed the "Target
Membership" Targets & Groups column, unchecked all the individual
files in the new target, and added a new .c file #including all the
others. It builds a fast "single-file" final version, and it's easy
to switch to the multi-file target for a slower app but with faster
compiles, editing, and debugging. I hope Xcode starts working better
with larger files soon, but in the meantime this works perfectly well.
Since this prosaic trick doubles the speed of the app (which has many
hot loops, not just the one described), it'll be interesting to apply
it to my other compute-bound apps....
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden