• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Puzzling performance difference after refactor
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Puzzling performance difference after refactor


  • Subject: Re: Puzzling performance difference after refactor
  • From: John Lunt <email@hidden>
  • Date: Fri, 30 Jun 2006 22:12:44 +0100

On 30 Jun 2006, at 21:52, Steve Checkoway wrote:


On Jun 30, 2006, at 1:13 PM, Bill Monk wrote:
Sharking the hot loop for the two versions is interesting. In both, of course, there's a function, let's call it A, which takes most the time, since that's where the work is done. Function A calls B, C, and D.

Shark shows that in the slow, multi-file app, function B is taking 44% of the time spent in A.

In the single-file, fast version, Shark shows that B is statistically insignificant. There are lines near B which show values as small as 0.1% in the Self column, but in the fast version, B has no entry in the Self column.
Yet in the slow version, B shows 44%.

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.


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?


I believe its more general than that. (Almost) all optimization in GCC 4.0 is done at a file level.
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.

Best wishes,

John.


_______________________________________________ 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
References: 
 >Puzzling performance difference after refactor (From: Bill Monk <email@hidden>)
 >Re: Puzzling performance difference after refactor (From: Steve Checkoway <email@hidden>)

  • Prev by Date: Re: Puzzling performance difference after refactor
  • Next by Date: Re: Puzzling performance difference after refactor
  • Previous by thread: Re: Puzzling performance difference after refactor
  • Next by thread: Re: Puzzling performance difference after refactor
  • Index(es):
    • Date
    • Thread