Skip to content

Conversation

akarnokd
Copy link
Collaborator

@akarnokd akarnokd commented Jun 27, 2018

This PR improves the counted Buffer operator by having dedicated exact (count == skip) and gapped (count < skip) implementations because these cases require only one buffer to be handled instead of the overhead of a queue holding at most one buffer.

The PR also adds a benchmark to verify the gains:

 // * Summary *

BenchmarkDotNet=v0.10.14, OS=Windows 7 SP1 (6.1.7601.0)
Intel Core i7-4770K CPU 3.50GHz (Haswell), 1 CPU, 8 logical and 4 physical cores

Frequency=3418007 Hz, Resolution=292.5682 ns, Timer=TSC
  [Host]     : .NET Framework 4.7.1 (CLR 4.0.30319.42000), 64bit RyuJIT-v4.7.255 8.0
  DefaultJob : .NET Framework 4.7.1 (CLR 4.0.30319.42000), 64bit RyuJIT-v4.7.255 8.0

// Before
  Method |     Mean |    Error |   StdDev |   Gen 0 | Allocated |
-------- |---------:|---------:|---------:|--------:|----------:|
   Exact | 451.4 us | 2.592 us | 2.425 us | 49.8047 | 205.57 KB |
    Skip | 426.2 us | 4.431 us | 4.145 us | 40.5273 | 166.51 KB |
 Overlap | 459.6 us | 3.067 us | 2.869 us | 49.8047 | 205.57 KB |


// After
  Method |     Mean |    Error |   StdDev |   Gen 0 | Allocated |
-------- |---------:|---------:|---------:|--------:|----------:|
   Exact | 410.2 us | 1.822 us | 1.615 us | 49.8047 | 205.43 KB |
    Skip | 400.0 us | 2.446 us | 2.168 us | 40.5273 | 166.37 KB |
 Overlap | 458.8 us | 2.248 us | 2.102 us | 49.8047 | 205.57 KB |

Improvement of Exact: 9.1%
Improvement of Skip: 6.1%

The Overlap (aka original algorithm) is practically the same within the noise range.

I've tried with a non-modulo algorithm for Overlap but it consistently produced 10 us slower results. I'm not sure why; I assume the special small numbers in the benchmark (1, 2) were JIT'd into binary-and and thus was much faster than an increment-test-store approach like the other two.

{
var idx = _index;
var buffer = _buffer;
if (idx == 0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer if you test here for buffer == null. I know it's the same, but when I read it the first time without knowing the end I was a little bit alarmed.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would be logically incorrect because once the short buffer ends after count, there is a window between count + 1 .. skip where buffer is null and no new buffer should be created.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, the conversation page shows your comment for line 46 but the changes page shows this for line 125:

image

@danielcweber danielcweber merged commit 657da13 into dotnet:master Jun 28, 2018
@akarnokd akarnokd deleted the BufferCountImprovement branch June 28, 2018 15:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants