Highly compressible data
dotnet/runtime#118457 (comment) includes a comparison and sample benchmark that includes a large number of iterations of highly-compressible data. This regressed in 9.0 and was missed. We should add a benchmark to cover that.
[Benchmark]publicvoidCompressionTest(){vartestData=_testData[TestFile];testData.CompressedStream.Position=0;using(varz=newDeflateStream(testData.CompressedStream,CompressionMode.Compress,true)){for(inti=0;i<testData.Iterations;i++){z.Write(testData.Data);}}}https://github.com/dotnet/performance/blob/main/src/benchmarks/micro/libraries/System.IO.Compression/TestData/alice29.txt should fit the bill, so simply adding some iterations to
| publicvoidCompress() |
| { |
| CompressedFile.CompressedDataStream.Position=0;// all benchmarks invocation reuse the same stream, we set Postion to 0 to start at the beginning |
| |
| varcompressor=CreateStream(CompressedFile.CompressedDataStream,level); |
| compressor.Write(CompressedFile.UncompressedData,0,CompressedFile.UncompressedData.Length); |
| } |
might be enough to capture.
Heap fragmentation
dotnet/runtime#117949 addresses a case where removal of our custom allocator regressed performance on windows x64.
We were able to reproduce that with a benchmark that @stephentoub wrote:
usingBenchmarkDotNet.Attributes;usingBenchmarkDotNet.Running;usingSystem.IO.Compression;BenchmarkSwitcher.FromAssembly(typeof(Bench).Assembly).Run(args);publicclassBench{privateBarrier_barrier=newBarrier(Environment.ProcessorCount-1);[Benchmark]publicvoidTest(){Task.WaitAll(Enumerable.Range(0,_barrier.ParticipantCount).Select(_ =>Task.Run(()=>{_barrier.SignalAndWait();for(intlength=1;length<1000;length++){byte[]buffer=newbyte[length];Random.Shared.NextBytes(buffer);using(varz=newZLibStream(newMemoryStream(),CompressionMode.Compress)){for(inti=0;i<100;i++){z.Write(buffer);}}}})).ToArray());}}| Method | Runtime | Mean | Error | StdDev | Ratio | RatioSD |
|---|
| Test | .NET 8.0 | 153.2 ms | 3.05 ms | 8.44 ms | 1.00 | 0.08 |
| Test | .NET 9.0 | 289.5 ms | 5.64 ms | 8.61 ms | 1.90 | 0.12 |
Highly compressible data
dotnet/runtime#118457 (comment) includes a comparison and sample benchmark that includes a large number of iterations of highly-compressible data. This regressed in 9.0 and was missed. We should add a benchmark to cover that.
https://github.com/dotnet/performance/blob/main/src/benchmarks/micro/libraries/System.IO.Compression/TestData/alice29.txt should fit the bill, so simply adding some iterations to
performance/src/benchmarks/micro/libraries/System.IO.Compression/CompressionStreamPerfTestBase.cs
Lines 58 to 64 in b8a4259
Heap fragmentation
dotnet/runtime#117949 addresses a case where removal of our custom allocator regressed performance on windows x64.
We were able to reproduce that with a benchmark that @stephentoub wrote: