On Mar 12, 2009, at 10:29 AM, John Engelhart wrote:
Actually, this isn't a "micro-benchmark".
If you aren't displaying the results, responding to user events, keeping an application state up to date and otherwise doing all of the things that need be done in a real world application, it is -- effectively -- a micro-benchmark.
In the context of an application, such processing is likely to be on a secondary thread and there is likely to be synchronization of data between threads. The overhead of the write barrier (which is spin lock contention under the covers, most likely) will be somewhat offset by the vast decrease in the cost of moving objects between threads, for example.
Think about processing HTTP server logs, and then performing more regex operations the further massage the end results (ie, the host only portion of the referrer).
Sure -- and if I were writing a Cocoa application to do exactly that, it would be doing all kinds of UI updates during the process to keep the user up to date on progress, give them a feel for whether the analysis is moving along in the correct direction, etc,etc,etc.... and all of that graphics related chatter is very likely going to far outweigh the CPU cycles consumed by the actual data processing bit.
If I were writing a command line tool to process log files in batches -- which I have done many times on the scale of 10s of GB of logs produced per day -- I wouldn't use Cocoa or Objective-C at all.
Don't get me wrong -- I'm not saying that you haven't found a particular test where, at the extreme, there is a significant chunk of performance cost for using GC vs. Non. And I still want to see the bug # with binary attached.
b.bum _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
