On Thu, 2 Nov 2000, Patrik Stridvall wrote:
> > * Is optimizing the code based on these results really that good for
> > real life performance for 16bit applications.
>
> One thing that is important to note is that Win16 is slower than Win32
> because the Win16 API almost always converts it paramters and calls
> the corresponding Win32 API.
>
> This should probably not be optimized for maintaince reasons.
I agree.
[...]
> This uses an O(n) algoritm but can be implemented
> with and O(log(n)) algoritm one I think.
>
> > 21.52 24.1 1.1 PolyLine
This kind of optimisation, i.e. at the algorithmic level, may be
useful. Although it's probably not a priority right now.
[...]
> I have slight optimized it as I said above.
> MoveTo16 now directly calls MoveToEx(32)
> instead of MoveToEx16. This might make
> some difference if the difference is
> this large in the benchmark.
Doesn't this contradict your first point above?
This will probably not make a big difference. Look at the difference
between MoveTo and MoveToEx for instance:
Ratio Win Wine Test
11.06 7810000.0 706000.0 MoveTo
8.78 6290000.0 716000.0 MoveToEx
In the code MoveTo16 calls MoveToEx16 and does one MAKELONG.
That's the only difference. MoveToEx seems to do much better than
MoveTo but that's only because Windows's MoveTo is 24% faster than its
MoveToEx.
If we look at Wine's results we see that there's only a 1%
difference. So I expect that calling MoveToEx(32) directly will gain us
at most 1% since we skip 1 call but still have to do things like the
MAKELONG the CONV_POINT32TO16 and other parameter conversions. So it's
probably not worth it.
--
Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/
The greatest programming project of all took six days; on the seventh day the
programmer rested. We've been trying to debug the *&^%$#@ thing ever since.
Resume: design before you implement.
