Re: [Musicpd-dev-team] Remove duplicate optimisation for volume

[Matthias Larisch]

Am Thu, 15 Aug 2013 22:57:25 -0400
schrieb andrew cooke and...@acooke.org:

 
 Hi,
 
 I was just looking through the mpd source and noticed that the optimisations
 in ReplayGainFilter::FilterPCM duplicate code in pcm_volume.  So the following
 code would be equivalent.
 

Hi,

While I agree on the second case we save one memcpy on the first case.

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.

Regards,

Matthias


 
 diff --git a/src/filter/ReplayGainFilterPlugin.cxx
 b/src/filter/ReplayGainFilterPlugin.cxx
 index 446264c..3b320c3 100644
 --- a/src/filter/ReplayGainFilterPlugin.cxx
 +++ b/src/filter/ReplayGainFilterPlugin.cxx
 @@ -181,20 +181,7 @@ ReplayGainFilter::FilterPCM(const void *src, size_t
 src_size,
  {
  
 *dest_size_r = src_size;
 -
 -   if (volume == PCM_VOLUME_1)
 -   /* optimized special case: 100% volume = no-op */
 -   return src;
 -
 void *dest = buffer.Get(src_size);
 -   if (volume = 0) {
 -   /* optimized special case: 0% volume = memset(0) */
 -   /* XXX is this valid for all sample formats? What
 -  about floating point? */
 -   memset(dest, 0, src_size);
 -   return dest;
 -   }
 -
 memcpy(dest, src, src_size);
  
 bool success = pcm_volume(dest, src_size,
 



signature.asc
Description: PGP signature
--
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=48897031iu=/4140/ostg.clktrk___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team

Re: [Musicpd-dev-team] Remove duplicate optimisation for volume

[Max Kellermann]

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=48897031iu=/4140/ostg.clktrk
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team