CVS update: gnucash/src/engine

Rob Browning rlb@cs.utexas.edu
15 Feb 2001 15:51:34 -0600


linas@linas.org writes:

> Its a cardinal sin to not worry always, constantly, and continutally
> about performance.  But don't get me started, I'm not sure I want to
> go there today.

IMO allocation often constitutes only a small fraction of the whole of
issues affecting performance, and opinions vary *widely* about what
constitues a performance win in the big picture.  WRT allocation,
depending on the allocator and the cache locality issues, the right
answer to any given question about performance can be anything but
trivial.

Anyway, different tasks require different metrics, some involve code
and code performance, and others don't.  IMO this isn't as black and
white an issue as you seem to make it sound, but it seems clear to me
that the best investment of time is nearly always in trying to weiner
on the 10% of the time critical code, making concessions to clarity
there when necessary, and to keep everything else as simple and clear
as possible whenever that doesn't critically harm performance.

For example, since you brought up C macros, I often consider them an
overall performance loss, if hard to understand unless they *really*
help a performance critical region.  For many tasks, the number of CPU
cycles lost on something like this is dwarfed by the mental cycles
spent trying to understand what's going on, and if the compiler's
smart, which many are these days, the macro might not evern help.  To
be fair, this observation is not specific to macros -- I don't mean to
pick on them.  The same problems exist with complicated non-macro code
too.

As a broader example, no one in their right mind would try to write
some of the complex AI algorithms in a language without garbage
collection.  That would be a *huge* performance loss wrt to
programmers time, and quite possibly even wrt runtime-performance.

IMO it would be like trying to hand-code assembly to search your
filesystem for all the files named "foo" rather than just using 'find
-name "foo"'.  This would only be worthwhile if you were designing a
"foo file find" server, and even then it'd be debatable.  In the AI
case, the smart GC algorithms have gotten much smarter, and for
complex structures, and if tuned for the local machine's VM heirarchy,
may do better than you can.

Of course -- IMO YMMV whatever.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930