Re: [OT] Premature optimizations (was: Where is NSList?)
Re: [OT] Premature optimizations (was: Where is NSList?)
- Subject: Re: [OT] Premature optimizations (was: Where is NSList?)
- From: Marcel Weiher <email@hidden>
- Date: Thu, 29 Jul 2004 23:07:15 +0100
On 29 Jul 2004, at 12:50, Allan Odgaard wrote:
On 29. Jul 2004, at 11:17, Steve Checkoway wrote:
I'd suggest using NSArray/NSMutableArray for ordered collections,
and only worrying about their access characteristics if use and
profiling of your application point to them as a performance issue.
This is a *very* naive view which may well lead to O(n^2) or worse
implementations of O(1) problems!
Programmers are notorious for optimizing the wrong code.
What is your basis for that statement? which programmers are you
referring to?
The whole lot...
The pervious point was well made and perfectly valid.
I disagree. If you understand time complexity, you mostly do not need
to profile your code to know how well it scales,
...and this is exactly the type of programmer he was referring to!
Goodness gracious!
Anyway, just two days ago, I noticed that an app was slower than it
should have been. I *knew* that some of the update algorithms were
somewhat braindead, I had implemented them that way on purpose
(DTSTTCPW), and they weren't exactly quadratic, but N*M, which is close
enough, so it was time to do the work I had avoided at the beginning.
Wrong!
Running a profile revealed that 80% of the CPU time was being spent
converting strings to dates, putting in two caches ( ~ 6 lines of code)
completely cured the problem.
and if you have reusable data structures, you do not need to spend
extra time making it right from the start,
PRECISELY. If you have reusable data structures, then you can just use
plop in a different one when necessary.
rather than fix it when users complain that the app is useless for
larger quantities of data, or just ignore the problem, which seems to
be the case for half the apps I use... ;)
In my experience, the slowest apps are the ones that were optimized
prematurely, the fastest ones are the ones that were optimized only
AFTER profiling.
We have a lot of people which program whom doesn't have in depth
knowledge about data structures and time complexity, and I think it's
a disservice to these to almost label optimizations as a bad thing.
Quite the contrary. Premature optimization is the root of all (almost)
all evil. (Actually, I have now come to the conclusion that premature
*abstraction* is the root of all evil, but that's a different topic,
and in some ways just a generalization anyway...;-)
What we could preach is how to do proper optimizations, and choosing
the proper data structure is the first step, which was all the OP
wanted...
Nope. *Proper* optimization does not happen before the profiler hasn't
run.
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
1d480c25f397c4786386135f8e8938e4
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.