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: Tim Ramsey <email@hidden>
- Date: Thu, 29 Jul 2004 19:47:59 -0500
- Resent-date: Thu, 29 Jul 2004 19:57:57 -0500
- Resent-from: Tim Ramsey <email@hidden>
- Resent-message-id: <email@hidden>
- Resent-to: email@hidden
On Thursday, July 29, 2004, at 05:07 PM, Marcel Weiher wrote:
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.
An interesting story, and probably educational, but no single
apocryphal story can be used to resolve an argument about general
principals.
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.
I may be wrong, but I don't think this is the sense with which
"reusable structures" was originally used.
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
I have been following this discussion with interest as both choice of
appropriate data structures and effective optimization are extremely
important to me. I will confess that my viewpoint is parochial as I
have spent most of 40 years as an algorithm designer and builder of
huge physics simulations on supercomputers. Some of this stuff is based
on graph theory where linked list methods are often the only viable way
to go. (Why is way OT).
I find it hard to buy the feeling conveyed by much of this discussion
that there is some kind of either/or choice between selecting data
structures and optimizing code. Both are important. I doubt many of the
participants actually think things are that black and white. Just try
to optimize your way out of having painted yourself into a corner by a
bad data structure choice. Conversely, just try to fix poor
implementation, except accidentally, by a change of data structures.
I am surprised that no one has yet pointed out that it is not just
about speed. Choice of appropriate data structures can vastly simplify
code, making it much more maintainable. Coding, debug and maintenance
go faster and optimizations are easier to do.
I heartily agree about the importance of basing optimization on testing
as Marcel says. Well-chosen data structures can facilitate such tests.
It is wrong to assume people have no sense. With experience and
analysis, we know that some architectures are faster/better for a
particular problem than others. Choosing one of these does not
constitute premature optimization. Conversely, having chosen one of
these, we are not justified in blindly going in and tweaking code
without proper testing.
An alternate definition: "Proper" optimization has happened when either
1) The response time of the application is satisfactory to all
or
2) The code is as good as the state of the art can make it and we are
hardware bound.
The manner of achieving the above is irrelevant although profiling is
among the most potent tools.
What was the argument about again?
Tim
_______________________________________________
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.