Comments on: Response: Don’t Forget The ‘C’ in Objective-C!

By: Rich

Rich — Fri, 13 Apr 2007 12:32:47 +0000

Premature optimizaiton is the root of all evil…

–Donald Knuth

By: Jon Hendry

Jon Hendry — Mon, 09 Apr 2007 19:00:07 +0000

To give the author credit, he does note that the code in his example doesn’t really need the change, and notes that such an optimization would make more sense in code that operates on non-Unicode strings in a tight loop.

I think it can be marked up to the challenge of finding appropriately simple example code for the length and venue of the article. Ideally, it would have been example code that is in fact a tight loop. But that might have obscured things or required too much explanation.

A better, longer article could probably be written which gives examples of falling back from Cocoa to all the various other apis: Carbon, Core Foundation, Quartz, Mach, BSD, etc in various contexts.

But I don’t know if that would be appropriate for The Reg.

By: Jesse Tayler

Jesse Tayler — Mon, 09 Apr 2007 16:52:24 +0000

Bill has a really IMPORTANT point here, regardless of the example used, or the original article. I see programmers all over the place pronounce that “Oracle handles a tiny-int better than an unsigned int” or that “NSString is slow compared to some lines of assembly or lower level C. However, that fact is really not important if you see a whole project as something that must be maintained and delivered on time. Rarely are these “truths” about performance really behind performance problems in the real world use of a large scale project or system. Again, if you are not taking measures, you are not really focusing on where performance troubles lie and it is just that simple. Many engineers I’ve met do not like to be the “Scientist” part of a Computer Scientist, but without measures, tests and proof these “facts” about low level code elements are just tiny factoids that are not truly relevant to a project as a whole. I get the sense people like to show off their knowledge of these factoids, but do not like to set up Scientific measures and tests that concern the entire project. When you use Scientific measures, you basically never find out that it was the way you handled a string somewhere but rather you’ve found that a far larger paradigm or whole approach must be rethought and redesigned specifically.

By: Corey O'Connor

Corey O'Connor — Mon, 09 Apr 2007 16:45:05 +0000

“Measure the damned performance before applying error prone optimizations!”
Indeed! Even designing for simplicity and clarity before optimizing can fail unless quantitative measurements are used to prove the optimizations. I now tell people to follow this, slightly ammended, philosophy:
Rules of optimization:
1. Don’t do it.
2. Experts only: Don’t do it yet, and only if quantitative measurements exist to back up any claims.

By: mikeash

mikeash — Mon, 09 Apr 2007 16:17:32 +0000

The original article “optimized” something that wasn’t a bottleneck down to broken code. The proper C equivalent to the NSString code is going to be at least as complicated, but we didn’t get to see it, because the article’s author was more concerned with speed than correctness. The original article was useless at best, dangerous at worst.

By: Vinpo

Vinpo — Mon, 09 Apr 2007 12:54:17 +0000

This whole argument is nice and all as long as nobody uses it as an excuse to justify any lack of knowledge or skill. I’m not sure if anyone is doing this or not, but if you don’t know your TLB then study instead of making up excuses. Sometimes I wonder about the average education level of application programmers, I hope this is largely unjustified. A PhD doesn’t mean you must stop learning more things, ok?

By: zz

zz — Mon, 09 Apr 2007 11:21:05 +0000

All things equal, less code is more readable and less bug-prone.

In this case, the strstr version *had* a bug as detailed in the comments. I also think it makes code a lot less readable if you mix C-style string api and NSString api in the same project. (especially when the C string api has method names such as “strstr” instead of “rangeOfString” like you have in nsstring).

So the original longer version was more readable and less bug-prone IMO. Personally I would just check the OpenGL api for an existing ‘check for certain opengl extension” method.

By: bbum

bbum — Mon, 09 Apr 2007 06:52:37 +0000

Fair enough — I’ll certainly attest to the fact that people commonly use a hammer to drive a screw and avoiding that was one key subtext to the article.

Still, optimization without analyzation is largely pointless. In that context, a simple “components separated by string” combined with “containsObject” is pretty damned simple/readable.

By: zachrahan

zachrahan — Mon, 09 Apr 2007 06:31:18 +0000

Speed isn’t even an issue here. The article pointed to a four or five line stanza of code that could be replaced with a single function call. Ignore claims of speed, etc. (which the article didn’t really press), and what you have is a change whereby a relatively large amount of code in a “high level” API can be replaced by a lot less code in the “lower level API” because the impedances match (e.g. C string functions for C strings).

All things equal, less code is more readable and less bug-prone. Now, not always are things equal, especially with regard to bug density (say the guy was talking about using strcpy instead of higher-level APIs)… But to read (and discard) this article as one about optimization is, I think, a mischaracterization.

By: bbum

bbum — Mon, 09 Apr 2007 06:12:37 +0000

I stand firm by the opinion that any article claiming that a particular API or optimization should be applied without quite explicitly calling out the need to actually analyze said code in context of execution is misguided and, likely, incorrect.

Barring that particularly huge flaw in the article, in this particular case — and as Rosyna also calls out — the higher level string handling APIs, be they NS or CF, aren’t really that slow and are often damned fast for particular cases while also avoiding the need to roll your own encoding handling code.

The article is mediocre, at best.