• 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: Performance problem with GC enabled
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Performance problem with GC enabled


  • Subject: Re: Performance problem with GC enabled
  • From: Marcel Weiher <email@hidden>
  • Date: Fri, 13 Mar 2009 01:20:57 -0700


On Mar 12, 2009, at 8:39 AM, Bill Bumgarner wrote:

On Mar 12, 2009, at 6:04 AM, John Engelhart wrote:
[.... way too many words deleted.... ... please try to succinctly state issues in the future ....]


You have created a micro benchmark that demonstrates a significant bit of overhead from GC vs. non-GC.

He extracted a real-world example of a performance problem into an isolated test case. This is a good thing.


While micro benchmarks are certainly useful, they must be taken with a grain of salt. Specifically, a real world app is not generally going to go do, say, 10 bazillion of the operations in the micro benchmark one after the other with zero feedback to the user.

Since the reported performance is relative, the scale-factor in front is quite irrelevant. If you run it 10 times or 10 bazillion times, 2.8x slower is still 2.8x slower. However, having a large scale- factor is convenient for taking meaningful measurements of running time.


Typically, a real world app would have progress bar(s), live button (s), and displays that are updated.

So things that are not impacted by the GC dilute the effect?

GC was optimized for the real world situation.

This is not an 'optimization'. This is just saying that computers today are fast enough that for many non-data-intensive applications, there will be enough idle-time for the machine to catch up that people won't notice wether operations are 2.8x slower.


In Leopard, the GC overhead is generally less than 10% CPU overhead and 10% memory footprint overhead for the whole application.

While such sweeping generalizations can be useful, they must be taken with a grain of salt.


In some specific measurements [of Xcode, for example, comparing GC vs. non-GC performance], GC is actually significantly more efficient than non-GC.

Is that actually true?

In others, non-GC is still quite a bit more efficient. But, overall and for the general user experience, GC on Leopard beats the general 10%/10% mark.

Is that for operations that actually use GC, or does that also include operations that do not involve the GC at all?


And, just like every other component of Mac OS X, the goal is to make the collector faster, more efficient, easier to use, and more powerful with each successive release of Mac OS X.

Excellent!

Marcel

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Performance problem with GC enabled
      • From: "Paul Sanders" <email@hidden>
References: 
 >Performance problem with GC enabled (From: John Engelhart <email@hidden>)
 >Re: Performance problem with GC enabled (From: Bill Bumgarner <email@hidden>)

  • Prev by Date: NSManagedObject validateForDelete problem
  • Next by Date: Re: TXT Records with NSImages
  • Previous by thread: Re: Performance problem with GC enabled
  • Next by thread: Re: Performance problem with GC enabled
  • Index(es):
    • Date
    • Thread