RE: RE: [lwip-devel] UDP - transmission inefficiences

[Bill Auerbach]

>> I don't know that platform, but there's always the chance that the
>> previous code was better aligned for cache or the new code is slightly
>> worse because it uses too many local variables to store all of them in
>> registers...
>>
>> Anyway, 5% might even be below accuracy of the measurement...
>
>It does highlight the problem of trying to optimise lwIP in this way
>though, as improvements for one platform can unintentionally hurt
>another.

I seriously doubt this optimization is this case.  Although I agree with
this statement I believe one would have to work very hard to make a
non-trivial case where this is true.

>Ideally inlining would be left up to the compiler as it should be in a
>good position to know when it would help and when it would not, but not
>all compilers are sophisticated enough to do this well.

The change made is impossible for a compiler to optimize.  I wouldn't submit
a patch for something a compiler should or could do better with.  There is
room for improvement in the code base regardless of platform and compiler
optimizations.

Filling in the header one member at a time and forming the sum of each
member as you go *has* to be faster than filling in the header one member at
a time and then calling a function to do the checksum of the header.  Even
if the data is cached, the existing code has to read each member twice.  And
it is adding in the zeroed checksum field which isn't done in the inline
version.

I spent 2 months optimizing my one platform and was able to quantify each
change. Regardless of how I measured it, it was consistent, and if I applied
2 changes, the improvement was the sum of each improvement measured
separately.

I have 2 other changes (ARP and IP) that had a noticeable improvement (that
a compiler cannot do) if there is interest in putting them in 1.4.

Bill