On 2013/08/16 12:27, Matthias Larisch <m...@matthias-larisch.de> wrote: > While I agree on the second case we save one memcpy on the first > case.
You got it, and that's the reason we have a similar optimisation in two code locations. The two optimisations are not equivalent and neither can be removed. > In my opinion we could save a memcpy for each filter by removing the > const attribute of first parameter... Maybe we need one memcpy at > start of filter chain (not sure) but not at every filter. What would we gain from this API change? Maybe then we could merge the two optimisations as Andrew suggested, but that's negligible. On the other hand, we'd need yet another buffer and yet another copy, even if the whole filter chain does nothing. I'd like to pay for (copy) overhead only if necessary. If the user wants software volume / replay gain, then he'll get it, at a certain cost. But those who disable those features shall not pay the price for features they don't use. Therefore, the "fast path" through the filter chain that simply returns the unmodified input buffer is there to stay. Max ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
