Re: Performance problem with GC enabled
Re: Performance problem with GC enabled
- Subject: Re: Performance problem with GC enabled
- From: John Engelhart <email@hidden>
- Date: Thu, 12 Mar 2009 13:29:45 -0400
On Thu, Mar 12, 2009 at 11:39 AM, Bill Bumgarner <email@hidden> 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.
Actually, this isn't a "micro-benchmark".
> 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. Typically, a real world app would
> have progress bar(s), live button(s), and displays that are updated.
While true, that does not apply in this case. This is creating an
NSArray of all the regex matches of a subject string. For example, I
just took a look at the size of my.yahoo.com page, which for me checks
in at about 450K. Executing a regex along the lines of "<[^>]+>"
generates an enormous amount of strings as a result. Or parsing a
comma separated file: first split on
"(?:\r\n|[\n\v\f\r\x85\p{Zl}\p{Zp}])", then on
",(?=(?:(?:[^"\\]*+|\\")*"(?:[^"\\]*+|\\")*")*(?!(?:[^"\\]*+|\\")*"(?:[^"\\]*+|\\")*$))".
Or creating a NSSet to get all the unique words in a string: [NSSet
setWithArray:[subjectString arrayOfStringsMatching:@"\\b\\w+\\b"]];
Or performing keyword matches for syntax coloring on several hundred K
source files. 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). Or syslog files...
So no, this is not a micro-benchmark. Performing these operations on
multi-megabyte files/strings is pretty standard stuff, which is why
it's important that it be fast. The for loop I posted isn't a
micro-benchmark either, it's the actual code, the part that turns the
NSRange results of all the matches in to strings. There's no way to
dodge this, it's just the nature of the beast, even though it might
have the superficial appearance that I'm micro-benchmarking object
creation and pointer storing in a tight loop.
_______________________________________________
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