• 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: Speed Traps
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Speed Traps


  • Subject: Re: Speed Traps
  • From: Andrew Pinski <email@hidden>
  • Date: Wed, 14 May 2003 22:45:55 -0400

There are better tools out there than gprof and Sampler.
Download the CHUD tools from Apple's developer web site
or if you have the December CD, they are on the CD.
Shikari, a tool that comes with the CHUD tool is a
profiler that can also use the PMC (performance mounter
counters) on the CPU, on the memory controller and
in the OS. It will also show you where in the
functions you are having trouble, assembly level,
but will tell you the file and line number if debug
information is there. The only thing Shikari does
not do right now is show how you got to the function,
you can use Sampler to find out that information.
Also it will show you what the stalls are due to code
scheduling. It can tell you where cache misses happens.
And if you are really worried about speed, I would use
a custom array structure which will always be faster than
any standard way, just do not use realloc all the time.

Thanks,
Andrew Pinski


On Wednesday, May 14, 2003, at 21:14 US/Eastern, publiclook wrote:

Don't guess about what takes time. You have already wasted you programming time needlessly. Profile your code and then you will KNOW where the time is being spent and you can optimize only the places that will give maximum benefit.

See Sampler and gprof that are already on your hard disk.

On Wednesday, May 14, 2003, at 06:07 PM, 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.

------------
John Nairn (1-801-581-3413, FAX: 1-801-581-4816)
Web page: http://www.mse.utah.edu/~nairn
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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: 
 >Re: Speed Traps (From: publiclook <email@hidden>)

  • Prev by Date: Re: Speed Traps
  • Next by Date: OpenGL -a success story and a question
  • Previous by thread: Re: Speed Traps
  • Next by thread: Re: Speed Traps
  • Index(es):
    • Date
    • Thread