ImageSharp Resize is 2x faster on Windows but 2x slower on Sandy Bridge + Linux compared to System.Drawing library

[mirshokraie]

I'm running resize method on an image with the following code using ImageSharp:
srcImage.Mutate(ctx => ctx.Resize(newSize.Width, newSize.Height, KnownResamplers.Bicubic, false));
The above resize runs 2x faster on Windows compared to System.Drawing library.
I use the following code in System.Drawing:

var newImage = new Bitmap(newSize.Width, newSize.Height, pixelFormat);
using (Graphics gr = Graphics.FromImage(newImage)) {
  gr.InterpolationMode = InterpolationMode.HighQualityBicubic;
  gr.PixelOffsetMode = PixelOffsetMode.HighQuality;
  gr.SmoothingMode = SmoothingMode.AntiAlias;
  gr.DrawImage(srcImage, new Rectangle(0, 0, newSize.Width, newSize.Height), new Rectangle(0,0,srcImage.Width,srcImage.Height), GraphicsUnit.Pixel); 
}

But when I run the same resize code using the same image on Linux, ImageSharp gets 2x slower compared to System.Drawing. The output quality in all cases look the same to me, and it also doesn't matter which image or what newSize I'm using.
I also checked the followings and they all returned true when running in Linux: sse42, sse41, sse3, sse2, Hardware Accelerated.
I'm wondering what could be the difference that same code, same image can run so much faster on Windows and a lot slower on linux compared to System.Drawing.

BTW thanks for such an amazing library! Since our code is executed under linux, we are currently in the process of transitioning from System.Drawing library to ImageSharp...

[JimBobSquarePants]

You need to provide a benchmark when making these kinds of claims.

[mirshokraie]

Do you want me to provide a command line project with the above code or just attaching the image I used and a table of running times?

[antonfirsov]

It's about the benchmarking method / code. Naive methods can be misleading, eg. if you run the method only once, the majority of the time you see is going to be the JIT time. The BenchMarkDotNet library can take care of these kind of problems for you so you get representative numbers.

[antonfirsov]

Just did a run of our parallel, large image LoadResizeSave benchmarks and got these results on my Linux VM:

BenchmarkDotNet=v0.13.0, OS=ubuntu 20.04
Intel Core i9-10900X CPU 3.70GHz, 1 CPU, 10 logical and 5 physical cores
.NET SDK=5.0.201
  [Host]   : .NET Core 3.1.17 (CoreCLR 4.700.21.31506, CoreFX 4.700.21.31502), X64 RyuJIT
  ShortRun : .NET Core 3.1.17 (CoreCLR 4.700.21.31506, CoreFX 4.700.21.31502), X64 RyuJIT

Job=ShortRun  IterationCount=3  LaunchCount=1
WarmupCount=3

|        Method | maxDegreeOfParallelism |       Mean |      Error |   StdDev | Ratio | RatioSD | Gen 0 | Gen 1 | Gen 2 | Allocated |
|-------------- |----------------------- |-----------:|-----------:|---------:|------:|--------:|------:|------:|------:|----------:|
| SystemDrawing |                     10 |   538.0 ms |   303.1 ms | 16.61 ms |  1.49 |    0.09 |     - |     - |     - |     17 KB |
|    ImageSharp |                     10 |   362.3 ms |   263.1 ms | 14.42 ms |  1.00 |    0.00 |     - |     - |     - |    890 KB |
|        Magick |                     10 | 1,357.7 ms | 1,199.3 ms | 65.74 ms |  3.76 |    0.33 |     - |     - |     - |     54 KB |
|       NetVips |                     10 |   188.6 ms |   254.1 ms | 13.93 ms |  0.52 |    0.03 |     - |     - |     - |     53 KB |

[mirshokraie]

@JimBobSquarePants
Resize only on Windows:
BenchmarkDotNet=v0.13.1, OS=Windows 10.0.19044.1466 (21H2)
Intel Core i7-3770 CPU 3.40GHz (Ivy Bridge), 1 CPU, 8 logical and 4 physical cores
.NET SDK=6.0.101
[Host] : .NET 6.0.1 (6.0.121.56705), X64 RyuJIT
DefaultJob : .NET 6.0.1 (6.0.121.56705), X64 RyuJIT

Method	Mean	Error	StdDev
ImagesharpResize	57.67 ms	1.138 ms	2.615 ms
SystemDrawingResize	2,013.19 ms	12.862 ms	12.031 ms

Resize only on Linux:
BenchmarkDotNet=v0.13.1, OS=centos 7
Intel Xeon E312xx (Sandy Bridge), 1 CPU, 4 logical and 4 physical cores
.NET SDK=6.0.101
[Host] : .NET 6.0.1 (6.0.121.56705), X64 RyuJIT
DefaultJob : .NET 6.0.1 (6.0.121.56705), X64 RyuJIT

Method	Mean	Error	StdDev
ImagesharpResize	110.6 ms	1.08 ms	0.90 ms
SystemDrawingResize	355.6 ms	5.45 ms	5.09 ms

[JimBobSquarePants]

None of these benchmarks are showing the behaviour quoted at the beginning of this discussion?

[mirshokraie]

@JimBobSquarePants The title of this topic comes from the fact that I was using stopwatch to calculate the time, and as I mentioned I realized it is not accurate after using BenchMarkDotNet, but as you can see (in the benchmark results I posted) the total time (load, save, and resize) for ImageSharp is almost twice more than System.Drawing on linux. It's probably because System.Drawing becomes fast in resize operation on linux while it's too slow on Windows (2 seconds on Windows vs 355 msec on Linux), and ImageSharp loses speed on loading and saving...

[br3aker]

We've encountered same difference in performance in 2021. System.Drawing is clearly cheating when re-encoding image without any modifications within the same format. Your example image before and after re-encoding with systemDrawingSrcImage.Save(saveStream, ImageFormat.Jpeg); yields binary equal file which is highly unlikely for a lossy format. I don't know if GDI is open source so I can't pinpoint the exact place where this happens.

To prove that, let's provide actual quality parameter to the encoder:

using var @params = new EncoderParameters(1);
using var qualityParam = new EncoderParameter(Encoder.Quality, quality); // MUST be of type long
@params.Param[0] = qualityParam;

Your original image uses all-ones matrix meaning it has a quality of 100, which is actually a very bad value for the jpeg images but it's still 'correct':

File size after re-encoding
System.Drawing: 11057 kb
ImageSharp: 11547 kb
original: 10992 kb

As you can see, it's no longer 'equal' in binary. And even while ImageSharp writes approx. 4.4% more bytes - it's still faster than System.Drawing when Avx2 is present and not that slower if there's only avx available:

ImageSharp - has Avx2 and Fma
// Encoding q=100 | color=YCbCrRatio420
// Elapsed: 5743ms across 20 iterations
// Average: 287,15ms

ImageSharp - only Avx which is not used so basically a Sse pipeline
// Encoding q=100 | color=YCbCrRatio420
// Elapsed: 6948ms across 20 iterations
// Average: 347,4ms

System.Drawing - explicit quality parameter
// Encoding q=100
// Elapsed: 6285ms across 20 iterations
// Average: 314,25ms

System.Drawing - no parameters at all, looks fishy 
// Decoding
// Elapsed: 2460ms across 20 iterations
// Average: 123ms

Can't say the same for the decoder - needs further research. Maybe it's an another speed hack, maybe it's simply faster - who knows. That's why full decode-resize-encode benchmarks matter - that way we're sure System.Drawing doesn't do some magic with caching or whatever :)

[mirshokraie]

I think the speed mystery is finally solved! Thank you all! :)

[tocsoft]

My theory here is that System.Drawing on linux isn't actually doing the same operation as we are or windows does.
That issue implies that InterpolationMode is being ignored and thus its likely not doing as much work.

This issue in libgdiplus looks like it could be related mono/libgdiplus#730

[mirshokraie]

@tocsoft That makes sense. I think this can explain why system.drawing suddenly becomes fast on linux... then I guess this kind of comparison between windows and linux may not be valid. I'll try to deploy the application on a newer machine with support for avx2 and fma and hopefully I can get a much better results on linux :)