> > Compiler capabillities aside it feel like its the
> > wrong level of abstraction. Since MapMode is
> > always constant (with the exception of SetMapMode
> > of course) throughout a function call the map mode
> > test need only be done once. But the compiler
> > can't know whether a call to a inbetween function
> > changes the map mode or not (which a human knows)
> > so it must evaluate the expression again even given
> > teoretically optimal use of common subexpression
> > elimination (CSE).
>
> Yes. But I was rather trying to search for a solution
> that affects maintainability of the code as little
> as possible, while still offering as much performance
> improvement as possible.
OK. As I said in earlier I think it will work quite
with the current code since the compiler will be able
to do CSE in most cases.
I mainly dislike it because it is IMHO on the wrong
abstraction level.
> Generally, the problem with performance optimizations
> is that they tend to make the code less maintainable,
> by introducing code duplication, special cases, even
> things like inline assembly etc. At least in the
> current state of Wine, I tend to think maintainability
> more important than performance ...
Indeed. Balancing optimization vs maintainabillity
is very difficult.
As I also said earlier "Premature optimization
is the root to all evil."
However optimizing function like X11DRV_LineTo isn't
really that premature it isn't likely to change very much.
> The solution that you're suggesting (checking the map
> mode only once in a function), would lead to code like
>
> if ( !MM_TEXT )
> {
> complex algorithm
> }
> else
> {
> copy of the same algorithm with minor changes
> }
>
> which I feel is less maintainable, as every change
> to the algorithm must now be done at least twice.
True. My lastest proposal involes having different functions
for the different cases (RAW, OFFSET, SCALE, LINEAR)
and that is in some meaning even worse.
However I only suggest doing this for functions that
are fully implemented and are is not supposed to be
changed very much like X11DRV_LineTo.
But perhaps you are right that we should wait with these
kind of optimizations until after Wine 1.0.
> Of course, in the present situtation the 'algorithm' is
> rather trivial, making this discussion academic, but it
> would still IMHO be a step into the wrong direction.
Well. How we handle these kind of issues are rather
fundamental and whichever way we choose to do it
will likely be used as optimization in almost every
GDI fucntion that depends on map mode and friends.
