Hacker News Reader

Comment by cageface | Hacker News Reader

Obj-C does not have a similar performance profile to C/C++. Method dispatch is far slower than vtables. I've personally witnessed a huge Obj-C dev project fall apart when the team couldn't get performance up to snuff, even with dedicated help from Apple's UI team. The rewrite in C++ is progressing nicely.

View on HN

And as someone who is currently writing high-performance ObjC code, and who has written internet-scale packets-per-second-metered code in C and C++, I call bullshit on this.

I have no doubt that method dispatch is significantly slower than vtables, but you're ignoring the fact that for performant code, plenty of C++ devs believe that vtables are far too slow as well. Large high-performance C-style projects are always struggling with the tension between the indirection that architects want to keep the system clean and the hardwired directness that the profiler says the system needs to be fast. ObjC didn't introduce this dilemma; function pointers did. It's so well known in C++ code that the MIT Click Modular Router even got distributed with a tool that automated de-virtualizing method calls.

In both C++ and ObjC, when dispatch gets scary, you write C code. The difference is that C++ pummels you about the head and shoulders for even considering writing straight C with naked pointers, while ObjC could care less.

I would rather avoid ObjC. I would rather build a large system out of any high-level language, from Scala to Ruby to Python to Lisp, and use an FFI to drop into C code. But I'd spend the rest of my career in ObjC without so much as a Bourne shell script to fall back on than I would willingly start another project in C++.

Worth reviewing:

http://www.mikeash.com/pyblog/performance-comparisons-of-com...

So on 64-bit architectures Obj-C messages are eight times slower than a vtable lookup. There's no way that could make or break an apps performance, right?

No, there isn't. Because in any application where that code path was at the top of your profile, you'd code around it with direct function invocation, just like people do in C++ with expensive chains of vtable calls (which you end up with in GoF-style code).

Nice try, though.

In many real world apps there just isn't a single chokepoint but overhead distributed over your entire object model. C++ gives you 8x the breathing room that Obj-C does before you have to start tearing your abstractions apart and coding direct. For a codebase of any real size that can easily be a dealbreaker.

This is why it's easy enough for advocates of python/php/ruby to say "just code the slow parts in c" but often far harder to actually do this without losing any advantage the higher level language bought you in the first place.

Comparing the amount of time it takes to refactor an expensive (inner-loop) series of message invocations into a direct function call to the amount of time it takes to recode Ruby in C and bridge it with an FFI is specious.

Dodging the point that often you don't have a bottleneck reducible to a few slow inner loops is more specious.

There's a huge difference between the overhead of a dynamic function call and a vtable lookup. No doubt there are some cases where even a vtable lookup is too expensive but there are millions upon millions of lines of production C++ in high-performance apps that use C++'s vtable dispatch.

What language would you choose to write something like Protools, Photoshop, Maya, Visual Studio etc in? Definitely not C and definitely not Obj-C.

There's millions upon millions of lines of production code, some of it (for instance, at the financial exchanges) millisecond-optimized, running in Java. What's your point?

Again, I simply call bullshit on the idea that you couldn't write ProTools or Photoshop in ObjC. The portions of those systems where you care deeply about performance can be written most effectively in bare-metal C anyways; it's a delusion of C++ programmers that all the shellac and geritol that C++ offers is giving them a major performance benefit. It's C++ that forces you to make a lifestyle decision by pretending that pointers are anything other than register-sized integers. ObjC is just enough object goop layered over straight C to make large programs maintainable.

I hate C++ as much as the next guy but the idea that the people behind essentially all the performance-critical desktop apps on the planet are just too dumb to move on is quite strange.

Again, I've seen first hand a big, native UI project crash and burn on Obj-C dispatch overhead that is now trucking happily along in C++. Have you?

I have never seen an ObjC program crash and burn under the weight of ObjC. I have seen two major C++ projects get rewritten, once to straight C and once to new flavor-of-the-month C++ (from ACE-style objecty GoF-y C++ to Alexandrescu-y template-y C++).

You talk like adoption of C++ is a testimonial to C++'s power. The fact is, the market picked C++. Your realistic choices for bare metal app dev are straight C, which you can use anywhere, or C++, which you can use anywhere. If you want native objects, you're going to use C++.

There are two places where ObjC is even an option:

* On Apple stacks.

* In SaaS/ASP/service backend code.

In both of those places, ObjC is better than C++. If you care about portability, write in C or JVM+C.

I don't understand the comparison you're drawing. On most platforms, they don't have the option of using Objective-C (support outside the Apple ecosystem could charitably be called "anemic"), and on Apple platforms, most native development is done using Objective-C.

Reply on news.ycombinator.com