Re: ObjC in time-critical parts of the code
Re: ObjC in time-critical parts of the code
- Subject: Re: ObjC in time-critical parts of the code
- From: Greg Titus <email@hidden>
- Date: Thu, 15 Jan 2009 23:39:33 -0800
Jens,
The point of what people are trying to tell you is that the result you
are getting (3ms per empty Objective-C call) is approximately 500,000
times longer than the time you ought to be getting (5-6ns). If an
Objective-C message send took 3 milliseconds (333 method calls per
second!), no useful software could ever have been written in the
language.
From your guess at the end of your post, ("message dispatcher
servicing") it is pretty clear that you don't really know what is
going on. Blaming the language environment for performance behavior
that is vastly different than any of the rest of us have ever seen is
not likely to be useful to you at all. There is something else
happening with your application.
We're just trying to save you the effort of rewriting and then
discovering that nothing about the timing problem has changed, because
you have misidentified the problem.
Good luck,
Greg
On Jan 15, 2009, at 11:20 PM, Jens Bauer wrote:
Hi Chris,
The rendering is not choppy in every frame.
I'm already using Shark often (now it's a bit easier just jusing
Activity Monitor, because it's always running anyway).
I know the Microseconds() call by heart, and there's nothing wrong
with it; it does work very well, and does not use much CPU-time.
I doubt that the performance tools are microsecond accurate; in my
case, it's important to go down to the millisecond level, since I'm
about to go 60 FPS, and would like my entire operation to stay at
least below 5ms (actually it uses 0.4 ms).
Love,
Jens
On Jan 16, 2009, at 01:32, Chris Hanson wrote:
Rather than cobble together your own measurement infrastructure
using old Carbon calls and NSLog, I recommend in the strongest
possible terms that you measure your application's performance
using purpose-built profiling and analysis tools like Shark and
Instruments.
Performance measurement may seem simple at first glance but it can
be very subtly hard to get right. That's why tools for it are
supplied with Xcode, and why they need explicit support from the
operating system.
-- Chris
On Jan 15, 2009, at 2:16 PM, Jens Bauer <email@hidden>
wrote:
Hi all,
I just want to let you know that I discovered I did a terrible
mistake today.
In other words: you don't have to learn from your own mistakes, if
you can learn from mine. =)
I investigated this, because my rendering was choppy.
The code...
- (void)renderObject
{
}
- (void)renderAll
{
UnsignedWide us;
double time;
Microseconds(&us);
time = ((double) us.hi) * 65536.0 * 65536.0 + ((double) us.lo);
[self renderObject];
Microseconds(&us);
time = ((double) us.hi) * 65536.0 * 65536.0 + ((double) us.lo) -
time;
NSLog(@"time:%.3fms", time * 0.001);
}
..often used around 3ms for the empty method "-renderObject".
It gave me the terrible result of up to 21ms spent in the empty
method!
-So I'd like to let you know that it's sometimes good to think "do
I really need this method?"
I will be rewriting around 8 of my large files for doing some
rendering, so they will be using C-routines instead of ObjC
methods, since I'm using them in a real-time environment.
My guess is that the message dispatcher probably needs to do
something else than servicing *my* application, so I believe it's
the nature of the environment, not a bug.
_______________________________________________
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
_______________________________________________
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