JimBobSquarePants/ResizeBenchmark-01-06-2017.md

Created June 1, 2017 12:07

Star (0) You must be signed in to star a gist
Fork (0) You must be signed in to fork a gist

Learn more about clone URLs
Clone this repository at <script src="https://gist.github.com/JimBobSquarePants/af7d2e01a410a0e54544f5e528a61fec.js"></script>
Save JimBobSquarePants/af7d2e01a410a0e54544f5e528a61fec to your computer and use it in GitHub Desktop.

ResizeBenchmark-01-06-2017

Raw

ResizeBenchmark-01-06-2017.md

BenchmarkDotNet=v0.10.1, OS=Microsoft Windows NT 6.2.9200.0
Processor=Intel(R) Core(TM) i7-6600U CPU 2.60GHz, ProcessorCount=4
Frequency=2742185 Hz, Resolution=364.6727 ns, Timer=TSC
  [Host]     : Clr 4.0.30319.42000, 64bit RyuJIT-v4.7.2046.0
  DefaultJob : Clr 4.0.30319.42000, 64bit RyuJIT-v4.7.2046.0

Method	Mean	StdDev	Scaled	Scaled-StdDev	Allocated
'System.Drawing Resize'	61.8849 ms	1.5651 ms	1.00	0.00	512 B
'ImageSharp Resize'	28.9082 ms	0.6396 ms	0.47	0.01	16.91 MB

FransBouma commented Jun 1, 2017

in-place resizing could work (block resize followed by bilinear pass?), but I bet they're not destroying the source buffer, so indeed 512Bytes seems impossible. You could try to measure the # of memory allocated using windows performance analyzer, it does have counters for that.

adamsitnik commented Jun 1, 2017

@JimBobSquarePants I added an issue to BenchmarkDotNet to track the native memory