I checked the keep_m_in_n block and found a possible bug in it. In the
work
function, the code wrote:
consume_each(d_n);
return d_m;
which I think it should be
consume_each(blksd_n);
return blksd_m.
while blks=std::min(noutput_items/d_m, ninput_items[0]/d_n).
Since both m and n of the block might change, which means the output to
input rate might change. I changed the set_output_multiple(m) to
set_relative_rate(d_n/d_m). And we made the set_relative_rate(d_n/d_m)
be
called in the set_m and set_n function to make sure the rate is updated
on
time.
To follow up on Martin’s point. First, yes, please either use the Issue
tracker or submit a patch/pull request via git and github.
Also, just pointing out a bug is one thing, but it’s also much easier
for
us to test and verify if you provide us with an example file.
That having been said, yes, I think your patch is correct. The current
behavior does not produce the wrong answer, but it’s wasting a ton of
computation time.
But I forgot that you actually submitted a patch in the email, so don’t
worry about opening an issue on this right now. I’ll take the patch and
check it in.
(btw, in a simple test I ran, this gave a 10x speedup on that block.)
Thanks!
Tom
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.