On Sep 1, 2013, at 18:26 , Uli Kusterer <witness.of.teacht...@gmx.net> wrote:
> Honestly, I wouldn’t use non-keyed archiving anymore these days. Either you
> need performance so badly that you create your own file format (or use
> something specialized for a particular need, like sqlite), or you use keyed
> archiving. It’s convenient, already debugged, and flexible.
I think we can agree that creating your own stable independently defined file
format will often be the best choice.
> Premature optimization is the root of all evil.
This gets (mis-)quoted out of context way too much (my emphasis):
"We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil”
It goes on as follows:
"Yet we should not pass up our opportunities in that critical 3%. A good
programmer will not be lulled into complacency by such reasoning, he will be
wise to look carefully at the critical code; but only after that code has been
identified. It is often a mistake to make a priori judgments about what parts
of a program are really critical, since the universal experience of programmers
who have been using measurement tools has been that their intuitive guesses
fail. After working with such tools for seven years, I've become convinced that
all compilers written from now on should be designed to provide all programmers
with feedback indicating what parts of their programs are costing the most;
indeed, this feedback should be supplied automatically unless it has been
specifically turned off.”
So far from being the missive against optimization as which it is commonly
portrayed, it is really just a rhetorical device, setting this idea in order to
demolish it in the “a good programmer will not be lulled into complacency by
such reasoning” line and then saying that we should optimize, but do it well
with measurement, even that measurement should be the default (something that’s
getting better!)
He also give some criteria for when optimization is justified (a good upper
bound for “small”):
"In established engineering disciplines a 12 % improvement, easily obtained, is
never considered marginal and I believe the same viewpoint should prevail in
software engineering”
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.103.6084
This is not a 12%, but a measured 4x improvement/slowdown in a part of the
software that can be considered critical (YMMV), IMHO very easily obtained.
Mind you, that doesn’t mean you have to change your opinion, but please don’t
use Knuth to support it.
Cheers,
Marcel
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
