Re: ObjC in time-critical parts of the code

On Mon, Jan 19, 2009 at 2:49 AM, Ben Trumbull wrote: >> Well no, it doesn't. ObjC has functions, by virtue of being a superset >> of C, but it does not have "member functions". You can write functions >> that are logically associated with a class, but this is a human >> construct, not one that the

Re: ObjC in time-critical parts of the code

> You're not going to do better straight out of the gate, > certainly not re-writing them in straight-C. Of course not. I'm not sure anybody has suggested that (long thread, could've missed it if it happened). But some of us have suggested not being automatically averse to C++/STL. Those container

Re: ObjC in time-critical parts of the code

> but the decision has *nothing* to do with non-virtual > member functions or other such oft-touted C++ speed improvements But actually, it does. The fact is that std::lower_bound is a template that specializes on the types of the iterators, so what you get is different code generated depending on

Re: ObjC in time-critical parts of the code

On Jan 19, 2009, at 4:21 PM, Kyle Sluder wrote: On Sun, Jan 18, 2009 at 7:10 PM, Bill Bumgarner wrote: Simple question: Is it better to pursue a 20%, or even 50%, improvement in drawing speed by rewriting in C++ or C than, say, preventing the 2, 3, 4, or more extra redraws that are happenin

Re: ObjC in time-critical parts of the code

On Sun, Jan 18, 2009 at 7:10 PM, Bill Bumgarner wrote: > Simple question: Is it better to pursue a 20%, or even 50%, improvement in > drawing speed by rewriting in C++ or C than, say, preventing the 2, 3, 4, or > more extra redraws that are happening prior to window flush? Don't laugh > -- I ha

Re: ObjC in time-critical parts of the code

Simple question: Is it better to pursue a 20%, or even 50%, improvement in drawing speed by rewriting in C++ or C than, say, preventing the 2, 3, 4, or more extra redraws that are happening prior to window flush? Don't laugh -- I have seen it happen. Often. I subscribed to this list jus

Re: ObjC in time-critical parts of the code

On Sun, Jan 18, 2009 at 9:23 PM, Ben Trumbull wrote: Several work arounds exist. The easiest is to create a static C member function (yes, ObjC has member *functions* which most people overlook). Well no, it doesn't. ObjC has functions, by virtue of being a superset of C, but it does not

Re: ObjC in time-critical parts of the code

From: Chris Williams > In 25 years in the computer business, I've seen precisely one example of > someone successfully re-coding around performance issues with the language > or library. And that was only because they coded a tiny snippet of > assembler that managed to fit into the pre-fe

Re: ObjC in time-critical parts of the code

On Sun, Jan 18, 2009 at 9:23 PM, Ben Trumbull wrote: > Several work arounds exist. The easiest is to create a static C member > function (yes, ObjC has member *functions* which most people overlook). Well no, it doesn't. ObjC has functions, by virtue of being a superset of C, but it does not hav

Re: ObjC in time-critical parts of the code

Ben Trumbull, Thank you for sharing your experiences on the subject in extent! Regards, Justin ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at c

Re: ObjC in time-critical parts of the code

In 25 years in the computer business, I've seen precisely one example of someone successfully re-coding around performance issues with the language or library. And that was only because they coded a tiny snippet of assembler that managed to fit into the pre-fetch cache of an 80286. Every other ti

Re: ObjC in time-critical parts of the code

On Jan 18, 2009, at 8:23 PM, Bill Bumgarner wrote: On Jan 18, 2009, at 6:05 PM, Justin Carlson wrote: I have also seen (unspecified) system libraries worsen considerably over time - 'faster over the course of OS releases' is not as sunny as I once believed. Believing system libraries will

Re: ObjC in time-critical parts of the code

On Jan 18, 2009, at 7:36 PM, Greg Titus wrote: On Jan 18, 2009, at 5:13 PM, Justin Carlson wrote: Jean-Daniel Dupas wrote: > > Each time you use KVC/KVO. Hi Jean-Daniel, Sorry if I misreading this, your response was short - it could mean a few things. I am inclined to think you were resp

Re: ObjC in time-critical parts of the code

On Jan 18, 2009, at 7:20 PM, mmalc Crawford wrote: On Jan 18, 2009, at 5:13 PM, Justin Carlson wrote: I would generally write: - (void)setMovie:(MyMovie *)newMovie { // make sure it is ok here In general your accessors should not perform validation; instead you should implement the

Re: ObjC in time-critical parts of the code

On Jan 18, 2009, at 6:05 PM, Justin Carlson wrote: I have also seen (unspecified) system libraries worsen considerably over time - 'faster over the course of OS releases' is not as sunny as I once believed. Believing system libraries will get faster is dangerous. You have filed bugs again

Re: ObjC in time-critical parts of the code

wine, wine, wine. My inline asm blocks look the same regardless of which language I use. Seriously, though, peek at /usr/include/objc/runtime.h and Behold that ObjC is ... uhm, well, C with a custom front end and some nice structs a library maintains for me. Okay, really very nice librar

Re: ObjC in time-critical parts of the code

>I've been watching this discussion w/great interest. Thanks. > > A lot of the discussion seems to be focused on micro-optimizations and little focused on systemic optimizations. > > One point that I have yet to see mentioned is the overall performance enhancements to be had by focusi

Re: ObjC in time-critical parts of the code

On Jan 18, 2009, at 5:13 PM, Justin Carlson wrote: Jean-Daniel Dupas wrote: > > Each time you use KVC/KVO. Hi Jean-Daniel, Sorry if I misreading this, your response was short - it could mean a few things. I am inclined to think you were responding to my question "how often do your subcla

Re: ObjC in time-critical parts of the code

On Jan 18, 2009, at 5:13 PM, Justin Carlson wrote: I would generally write: - (void)setMovie:(MyMovie *)newMovie { // make sure it is ok here In general your accessors should not perform validation; instead you should implement the appropriate KVV-conformant method.

Re: ObjC in time-critical parts of the code

Jean-Daniel Dupas wrote: > > An additional problem is that it does not scale well. Programs mature, > > objects are used beyond their initial intent, programmers come and go > > and that source becomes a nightmare to maintain. Getting back to good > > OO style, why take the messaging overh

Re: ObjC in time-critical parts of the code

On Jan 18, 2009, at 4:10 PM, Bill Bumgarner wrote: One point that I have yet to see mentioned is the overall performance enhancements to be had by focusing on embracing the high level services of the system. And by overall performance enhancement, I specifically mean that it lets you ship

Re: ObjC in time-critical parts of the code

All this reminds me a quote I found in an old PC Week: "Objective-C is the result of adding object facilities to C with the goal of making programmers more productive. The result differs greatly from C++, which adds objects to C without making computers less efficient: quite a different goal."

Re: ObjC in time-critical parts of the code

Quincey Morris wrote: > TBH (and more to the point) I strongly suspect it's true of everyone who's > expressed an opinion in this thread that it's not so much about the > suitability of the language to optimizations, but more about the skill > set of the individual with regard to the langu

Re: ObjC in time-critical parts of the code

On Sun, Jan 18, 2009 at 7:10 PM, Bill Bumgarner wrote: > I've been watching this discussion w/great interest. Thanks. > > A lot of the discussion seems to be focused on micro-optimizations and > little focused on systemic optimizations. > > One point that I have yet to see mentioned is the overal

Re: ObjC in time-critical parts of the code

I've been watching this discussion w/great interest. Thanks. A lot of the discussion seems to be focused on micro-optimizations and little focused on systemic optimizations. One point that I have yet to see mentioned is the overall performance enhancements to be had by focusing on embracin

Re: ObjC in time-critical parts of the code

Le 19 janv. 09 à 00:56, Justin Carlson a écrit : John Engelhart wrote: > On Sat, Jan 17, 2009 at 7:44 PM, Scott Ribe wrote: > >> TBH (and more to the point) I strongly suspect it's true of everyone > >> who's expressed an opinion in this thread that it's not so much about > >> the suitabi

Re: ObjC in time-critical parts of the code

John Engelhart wrote: > On Sat, Jan 17, 2009 at 7:44 PM, Scott Ribe wrote: > >> TBH (and more to the point) I strongly suspect it's true of everyone > >> who's expressed an opinion in this thread that it's not so much about > >> the suitability of the language to optimizations, but more abou

Re: ObjC in time-critical parts of the code

Michael Ash wrote: > > I would (personally) rather avoid caching selectors and debugging/ maintaining a > > program that used that behaviour when a well tested alternatives are built > > into another language's model. > > I agree that it's ugly, but it's good to have the option. Agreed. > M

Re: ObjC in time-critical parts of the code

Good grief, no. I'm not just talking about accessors. Try re-reading: > In addition, in many cases where Objective-C would have one or more method > dispatches in innermost performance-critical regions, with C++/STL you will > have NO FUNCTION CALL AT ALL, but rather direct pointer-based data acce

Re: ObjC in time-critical parts of the code

On Sat, Jan 17, 2009 at 7:44 PM, Scott Ribe wrote: >> TBH (and more to the point) I strongly suspect it's true of everyone >> who's expressed an opinion in this thread that it's not so much about >> the suitability of the language to optimizations, but more about the >> skill set of the individual

Re: ObjC in time-critical parts of the code

> Yikes! I hope you realize that for some of us of a certain computing > era, this statement looks quite strange. As if you said, perhaps, that > you were prone to reducing your fuel consumption by going back to > driving a Hummer. Yes, I realize that. Particularly for those who are only familiar

Re: ObjC in time-critical parts of the code

On Jan 17, 2009, at 15:49, Scott Ribe wrote: it's just that I'm more prone than many to optimize by throwing in some strategic C++ Yikes! I hope you realize that for some of us of a certain computing era, this statement looks quite strange. As if you said, perhaps, that you were prone to r

Re: ObjC in time-critical parts of the code

> The point here is that there's no reason to be afraid that > using ObjC will get you stuck in some performance hole that you can't > dig out of without a rewrite. Just to be clear re my earlier posts: I completely agree with that assessment; it's just that I'm more prone than many to optimize by

Re: ObjC in time-critical parts of the code

On Sat, Jan 17, 2009 at 2:02 AM, Justin Carlson wrote: > > Michael Ash wrote: >> >> Note that dispatch is not mandatory in ObjC either. It is possible >> (you get little help from the compiler, but it's not hard) to use >> either a vtable approach or a straight function call for method >> invocati

Re: ObjC in time-critical parts of the code

> Furthermore, vtables are not mandatory in all cases/calls. A > good optimizer (or properly written class) can overcome such > dependencies in several cases - optimization is far easier to > accomplish outside the constraints of the ObjC runtime. So you get > faster messaging, and more optimizatio

Re: ObjC in time-critical parts of the code

Michael Ash wrote: Note that dispatch is not mandatory in ObjC either. It is possible (you get little help from the compiler, but it's not hard) to use either a vtable approach or a straight function call for method invocation, as long as you don't mind the loss in functionality that this implie

Re: ObjC in time-critical parts of the code

On Fri, Jan 16, 2009 at 8:03 PM, Justin Carlson wrote: > Of course. Benchmarks were provided, which only cover a portion of the > subject. Furthermore, vtables are not mandatory in all cases/calls. A good > optimizer (or properly written class) can overcome such dependencies in > several cases - o

re: ObjC in time-critical parts of the code

Note no one that responded to Jens is stating that the Objective-C way of doing message dispatching cannot cause performance critical pathways to be "hotter" then desired compared to direct function calls, C++ vtable dispatching, etc. The point has been that just don't assume that is the source of

Re: ObjC in time-critical parts of the code

Hi Shawn, Thankyou for the detailed explanation. I've probably been too quick to jump to the conclusion, and even though it works better (I've still seen no chops), I agree that something else most likely have an impact on my application. On Jan 16, 2009, at 18:26, Shawn Erickson wrote: O

Re: ObjC in time-critical parts of the code

On Fri, Jan 16, 2009 at 2:26 PM, Justin Carlson wrote: > > Sorry if I come across as the devil's advocate on this one - I think there > should be another voice stating that objc use can slow a program. Note no one that responded to Jens is stating that the Objective-C way of doing message dispatc

Re: ObjC in time-critical parts of the code

Sorry if I come across as the devil's advocate on this one - I think there should be another voice stating that objc use can slow a program. Compared to C or C++, Objective C is a poor choice for performance critical code. Within performance critical zones, I will only use objc objects fo

Re: ObjC in time-critical parts of the code

On Fri, Jan 16, 2009 at 8:00 AM, Michael Ash wrote: > To repeat: something else is going on. If I had to guess (an we do since the OP didn't post any actionable information) the following possibilities come to mind... 1) logic bug in the code he replaced 2) memory management issue in the code h

Re: ObjC in time-critical parts of the code

On Fri, Jan 16, 2009 at 3:27 AM, Jens Bauer 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 ough

Re: ObjC in time-critical parts of the code

Le 16 janv. 09 à 11:19, Jens Bauer a écrit : Hi Jean-Daniel, On Jan 16, 2009, at 09:32, Jean-Daniel Dupas wrote: You don't want to understand. I'm sorry, if it appears to be like I do not want to understand. I've been working all night on this, and I'm quite sleepy right now. My results

Re: ObjC in time-critical parts of the code

Hi Jean-Daniel, On Jan 16, 2009, at 09:32, Jean-Daniel Dupas wrote: You don't want to understand. I'm sorry, if it appears to be like I do not want to understand. I've been working all night on this, and I'm quite sleepy right now. My results after changing to plain C are much better. My co

Re: ObjC in time-critical parts of the code

On Jan 16, 2009, at 3:27 AM, Jens Bauer wrote: :) I don't think any of us (except from Apple) knows what's exactly going on in there. ;) Um, at least one of the folks you're arguing with (not me) *is* from Apple. sherm-- ___ Cocoa-dev mailing

Re: ObjC in time-critical parts of the code

On 16 Jan 09, at 00:27, Jens Bauer wrote: 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. ;) Sure we do! http:

Re: ObjC in time-critical parts of the code

Le 16 janv. 09 à 09:27, Jens Bauer a écrit : 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 gettin

Re: ObjC in time-critical parts of the code

Le 16 janv. 09 à 09:03, Jens Bauer a écrit : Hi Jeremy, On Jan 16, 2009, at 04:52, Jeremy Pereira wrote: On 15 Jan 2009, at 22:16, Jens Bauer wrote: ..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

Re: ObjC in time-critical parts of the code

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

Re: ObjC in time-critical parts of the code

Hi Jeremy, On Jan 16, 2009, at 04:52, Jeremy Pereira wrote: On 15 Jan 2009, at 22:16, Jens Bauer wrote: ..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 go

Re: ObjC in time-critical parts of the code

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!),

Re: ObjC in time-critical parts of the code

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 mu

Re: ObjC in time-critical parts of the code

On 15 Jan 2009, at 22:16, Jens Bauer wrote: ..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 rewr

Re: ObjC in time-critical parts of the code

On Thu, Jan 15, 2009 at 2:16 PM, Jens Bauer wrote: > - (void)renderAll > { >UnsignedWideus; >double time; > >Microseconds(&us); >time = ((double) us.hi) * 65536.0 * 65536.0 + ((double) us.lo); >[self renderObject]; > >Microsecon

Re: ObjC in time-critical parts of the code

On Thu, Jan 15, 2009 at 2:16 PM, Jens Bauer wrote: > 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. This statement isn't even close to being correct. You really should st

Re: ObjC in time-critical parts of the code

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

Re: ObjC in time-critical parts of the code

On Thu, Jan 15, 2009 at 5:16 PM, Jens Bauer 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 chop

Re: ObjC in time-critical parts of the code

Le 15 janv. 09 à 23:16, Jens Bauer a écrit : 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 cod

ObjC in time-critical parts of the code

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)renderAl