OK. If you look back, this whole round of discussions was a
consequence of me saying "VIO in sndfile is ALSO good because...". I
didn't think it was really such a big deal in the first place: VIO is
already there, and I was able to accomplish my programming goals.
1) there's a reason to use value A
2) there's a different reason to use value B
3) there's no measurable difference in performance between A and B,
and thus the choice between 1+2 must be made on some other grounds
There is no choice to be made though. Sndfile doesn't have a userspace
cache, but does have a VIO layer that can be used by maniacs who want
to milk the last bit of performance (like me, possibly impairing
performance by premature optimization), or by those who need to
simulate in userspace a network driver. If we were to talk
counter-factually, no, I wouldn't want Eric to not write the VIO layer
that is present in sndfile at least after 1.0.21...
discarded. The ghosts of thousand dead standards will
back me up on
this one.
The situation you're describing, i.e. a "dead" standard still
applicable to the given platform, and thus able to mislead developers,
isn't so common, I believe.
Variations of less than about 500 bytes made no
statistically
significant difference to measured throughput.
I agree that the memcpy() cost is probably hardly measurable on a PC.
It might be measurable on a DSP though, or on a dedicated chip. So...,
Sure, but its because we care about performance, not
standards or
"rules". And I measured it first.
We might be at cross-purposes. My idea was to design the ideal
standards-compliant player and write the "perfect" code, for once (and
make sure that the libraries involved allow me to do it)
-- Dan