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: Michael Ash <email@hidden>
- Date: Fri, 16 Jan 2009 11:00:16 -0500
On Fri, Jan 16, 2009 at 3:27 AM, Jens Bauer <email@hidden> wrote:
> Hi Greg,
>
> On Jan 16, 2009, at 08:39, Greg Titus wrote:
>
>> 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.
>
> Just a comment.. It's not every invocation of the empty method that takes
> 3ms, it's just happening often.
> What I'm concerned about, is the peak values, that makes chops in my
> rendering. I thought it was the fault of my rendering code, and it did take
> me some time to figure out that it wasn't *inside* my rendering, but
> *outside* it, that the time was spent.
Preemptive multitasking can make any piece of code spontaneously
appear to take several milliseconds to execute, because it can get
preempted in the middle of running and not come back for quite a
while.
>> 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.
>
> :) I don't think any of us (except from Apple) knows what's exactly going on
> in there. ;)
Seriously?
Seriously?!!?!
To repeat what I said before, it's not magic. The Objective-C
dispatcher is nothing special. I, and many other people, have read the
source code to it. I believe that I can safely say that I understand
*exactly* what is going on in the dispatcher. And this is not a boast.
It's not like saying I know *exactly* what is going on inside the
Space Shuttle. More like I know exactly what is going on inside a
flush toilet. It just is not that complex. I'd wager at least half of
the people responding to you understand *exactly* what is going on
inside the Objective-C dispatcher as well.
>> 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.
>
> Uhm... Just to be stubborn: I changed the rendering to use plain C-routines,
> and now it doesn't get those high peak values anymore, and the chopping is
> gone.
> Yes, it's still an assumption, that this fixed it. I will try and see if it
> continues to work, but it definitely seems so much better right now.
You saw a problem, you made a change, the problem went away. You have
no idea *what the problem was*, just that your change made it
disappear. Until you actually find out what your program was doing
when it was spending all that time not working, your suppositions and
guesses are not really very useful.
Your supposition simply makes no sense. First, it is in conflict with
what everyone else has seen. Second, it is in conflict with what *you*
see. So you've removed all the Objective-C from your rendering code.
Your app is still Cocoa, right? Well guess what: Cocoa makes an
enormous number of Objective-C calls to do anything. You may have
eliminated all the ObjC calls from your own code, but every single
time you draw a frame to the screen I guarantee you that Cocoa makes
at least hundreds if not thousands of ObjC calls to make that happen.
If the ObjC dispatcher were really the problem, surely removing only
the calls in your own code would not have fixed it.
To repeat: something else is going on.
Mike
_______________________________________________
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