Optimizations.

[Marcel Moolenaar]

On Fri, May 16, 2003 at 12:26:19AM +0300, Narvi wrote:
> 
> > If you set yourself some simple goals and keep it high-level, then
> > we can all get used to the idea and we will probably find other
> > opportunities while we go. The end result can be much the same as
> > you try to achieve now, except that it has a bigger chance to be
> > integrated rather than some weird bunch on the side that plays
> > with compiler options "and shit".
> 
> nah, don't be too hard on them. they are volunteering for a large amount
> of hard work 8-)

Hard work it is, but the question of timing pops up: when there's
so much that needs to be done functionality-wise, how does the
hard work relate to progress? Of course, this being a voluntary
project, people are free to spend their time on things they like
to do. But with freedom comes opposition -- or something along
those lines :-)

If I would be asked to sacrifice implementation flexibility at a
time when things may need to be rewritten a couple of times to get
it right (think new platforms), I will be mostly insensitive to
arguments that limit that flexibility in favor of performance.

This is the root of my concern. Any team that seperates itself as
one that focusses on performance, is one that finds opposition and
the opposition may be too large to be able to do any performance
related work. It has to come natural, like enforcing style(9), or
security. Not that enforcing style(9) is without friction. But it's
a well-known and (almost :-) acceptable part of development. I
think performance has to be that too if we don't want it to be a
constant source of conflicts.

If a performance team could achieve that, then we're in for a
winner. /me thinks,

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel at xcllnt.net