Re: Speed Traps
Re: Speed Traps
- Subject: Re: Speed Traps
- From: Kevin Elliott <email@hidden>
- Date: Fri, 16 May 2003 11:28:17 -0700
At 16:07 -0600 on 5/14/03, John Nairn wrote:
I spent a day rewriting a custom expression parcer for what I hoped
would give me much more speed but the final result is now slower. It
is hard to believe it is slower; could I be missing some Cocoa speed
traps?
First version parced a NSString expression and evaluated as it went.
New version tokenizes the expression on the first past and then all
subsequent passes do no parcing, but just evaluate using the tokens.
The new version evaluation with tokens is slower than the first
version that parced AND evaluated on every pass. It does not make
sense and I am hoping I missed something or am using some Cocoa
feature in new version that is cause speed hang up?
One finding and maybe clue to speed traps:
In evaluating from tokens for expressions with groupings, I
recursive pass sub arrays of tokens to a function. If I allocate the
sub arrays and release them it it is slower than using autoreleased
arrays. In other words
subExpr=[[NSMutableArray alloc] initWithArray:...]
evaluate
[subExpr release];
is noticeably slower than
subExpr=[NSMutableArray arrayWithArray:...]
evaluate
I used the former method because I was concerned this large
calculation would >be building up a large pool of autoreleased
objects (several hundred thousand) >and slowing things down. I guess
that was wrong.
I'm not sure the previous answers were clear enough as to why this is
slower, so I thought I'd jump in and clarify.
The way autoreleases pools are implemented is (essentially) as a list
of objects (it would be very easy to implement them using
NSMutableArray, but I don't know if they are done that way).
Whenever an object is autoreleased (by calling [objext autorelease])
that object is added to the list. That's all that's done at that
point so obviously it can be very complete.
Now, at some later point the NSAutoreleasePool will be released
(normally when your code returns to the system in a normal GUI
application). Releasing the NSAutoreleasePool will in turn cause it
to release it's list of object to release and THEN release will get
called on all those objects.
Apples docs on the performance of Autorelease pools is somewhat
misleading (in my opinion). If you don't allocate anymore objects
than you "normally" would the performance is nearly the same as for
manually calling release. The only differences are that they will
tend to "clump" all your deallocations at the end of a event, rather
than throughout the entire handler and that because the memory is
being held they could become a problem is your using lots and lots of
memory for very short periods of time.
In short, there is a very good chance that the second method IS
faster, but your not including the deallocation time in the first
method like you are in the second.
--
__________________________________________
Kevin Elliott <
mailto:email@hidden>
ICQ#23758827 AIM ID: teargo
__________________________________________
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
| References: | |
| | >Speed Traps (From: John Nairn <email@hidden>) |