4 ms·
I think you might be grossly overestimating the performance penalty of Objective C's dynamic behaviours and message passing. I did too when I started programmin
by sjwright 15y ago
I think you might be grossly overestimating the performance penalty of Objective C's dynamic behaviours and message passing. I did too when I started programming with it, but then I did some quick benchmarking and realised the penalty was negligible bordering on nil.
For big loops, be comforted in knowing that message passing is aggressively cached; the second and subsequent calls are barely slower than a C method call.
And for those insanely big loops, with methodForSelector: you can bypass message passing entirely and call the method directly... you speed freak.
- pmarin 15y agoHave you replied the wrong thread? I was not talking about message passing.
- stopmi 15y agomaybe because reflection/introspection is done via "Objective C's dynamic behaviours and message passing"?
- leon_ 15y agoActually these are only convenience methods. For example to get a class name you can either use [object className]. Or you can use object_getClassName()/directly access "anObject->class_pointer->name" without dispatching any messages. The same goes for any other runtime attribute of an object.
- sorbits 15y agoC++ is used in environments where every byte and cycle counts, regardless of your personal experience, run-time meta data (and going via lookup tables) does have a big measurable overhead that many prefer to avoid. Adding to that, the things a C++ compiler can do at compile time (via static typing and full knowledge of the types) is pretty convenient and impressive, relying on these things to be done at run-time is often complex and/or require more code to be written by the programmer.
- leon_ 15y agoIn an environment where every byte and cycle counts I'd be using C. C++ has too much stuff going on behind the scenes. (Like hidden object copies, potentially bloated operators, etc.). If you can live with enabled exception handling (which is a performance toll) then some additional object meta data shouldn't be a problem.
- copper 15y ago> C++ has too much stuff going on behind the scenes. (Like hidden object copies, potentially bloated operators, etc.). The thing is, C++ is usually good about not charging you for features you don't use - and with the reasonably good debugging and profiling tools, most of the problems you mention above are fixable to get performance that is close (or equal) to C, with maybe better maintainability. To pick a not-so-random example of something that's difficult to implement in C as safely as in C++, see expression templates[1]. I'd be interested in something similar to what eigen does written in C. (Of course, the last time I did this minibenchmark, so-and-so's lapack library was still slightly faster than eigen :) The bottom-line, perhaps, is that if I'm writing a library, I'd do it in C simply because it's self-contained and has a nicely limited scope, and as a bonus is usable from oh-so-many other languages. If I'm writing an application that really, really requires serious performance, I'd prefer to use C++. [1] http://en.wikipedia.org/wiki/Expression_templates http://en.wikipedia.org/wiki/Expression_templates
- SamReidHughes 15y agoIt's very easy to avoid at least the problems you've mentioned by not making copyable objects and not defining bloated operators.
- leon_ 15y ago> not defining bloated operators Can you guarantee that for every 3rd party lib you use?
- SamReidHughes 15y ago