Re: [lwip-devel] SMEMCPY()

[Kieran Mansley]

On 12 Jun 2011, at 13:23, address@hidden wrote:

> Leon Woestenberg wrote:
>> Who did performance measurements on this, before converting our code over?
> What's the point in detailed performance measurements here? If I measured 
> this on my platform, that doesn't say it's optimized equally on your 
> platform, too.

I guess the point would be that if it made things worse on a platform that was 
tested, it would have been worth considering whether to make the change at all.

I agree that the theory behind this structure for the code is good, so I'm 
happy with the change, and now that it has been made the question about 
performance measurements is slightly moot, but it's still a reasonable question 
to ask.

> Anyway, this change has been mimal-invasive by defining both MEMCPY() and 
> SMEMCPY() to memcpy(), so I cannot see the downside of it.

The downside would be that if we previously had an efficient byte copy inlined 
in the code, and  that was replaced with a call to SMEMCPY() which maps to 
memcpy(), then we could have harmed performance.  However, I would rather see 
the inlined byte-copies replaced with a macro (like we have done with SMEMCPY) 
so that we can just implement that byte copy routine in one place, and result 
in cleaner code.  The missing steps is implementing the routine instead of 
defining SMEMCPY as memcpy(), and I think that is the critical point; should we 
do so in a generic way, or leave it up to those who know most about their 
platforms to do it themselves?  I guess it is not really an either/or choice, 
so if someone has a patch to define SMEMCPY in a more efficient way than 
memcpy(), then now would be a good time to try it out.

Kieran