poor performance about photosauce HOT 8 CLOSED

There are a number of differences that could lead to such a result. Here are a few:

MagicScaler is mostly managed code, while libvips is entirely native code. This means libvips will perform the same regardless of which .NET version you use. MagicScaler, on the other hand, is subject to the limitations of the .NET runtime and JIT.

To get the best performance from MagicScaler, you'll need to run on the latest version of .NET Core. If you must use .NET Framework, make sure you're running the app in 64-bit mode, as the 32-bit .NET JIT doesn't support any form of SIMD.

Make sure that "Prefer 32-Bit" box is unchecked in your project properties. It's checked by default for most .NET Framework project types.

Secondly, if you only test a single resize operation, you're timing the overhead of JIT compiling the large amount of managed code in MagicScaler, while libvips is pre-compiled to native code. You'll need to run at least one warm-up operation to trigger the JIT compile before measuring. Or you can use a tool like BenchmarkDotNet, which does a lot of work to make sure its results are accurate.

And finally, there are some differences in the way the JPEG codec used by libvips and the JPEG codec used by MagicScaler work. The built-in Windows codec is very fast with baseline JPEG but is slower with progressive-encoded JPEGs. To get a good picture of overall performance, you'll want to test with a variety of images.

from photosauce.

I missed that you said libvips CLI. This would make a comparison even more unfair. A single run of a .NET app includes the overhead of JIT-compiling your app as well as the MagicScaler code. It's very difficult to compare timings of any .NET app to an equivalent native app. You'd really need to set up your test using vips.NET in the same test app. Or better yet, clone the benchmark harness at https://github.com/bleroy/core-imaging-playground/ and plug in your own set of images.

from photosauce.

@saucecontrol
Yeah I'm using 64bit in preferences.
I measuring MagicScaler with Stopwatch class so it measures only operation of resize image without starting time of exe file.

My code:

Stopwatch stopwatch = new Stopwatch();
stopwatch.Start();

var settings = new ProcessImageSettings { 
 Width = 400
};

var outStream = new FileStream(targetPath, FileMode.Create);
MagicImageProcessor.ProcessImage(sourceImgPath, outStream, settings);

outStream.Dispose();

stopwatch.Stop();

Libvips is measured by ptime.exe so it contain exe startup time and end.

Still results are bad (24mpx file):
MagicScaler: 370ms
CLI libvips: 170ms

from photosauce.

Are you doing one or more warmup iterations to pre-JIT the code? The JIT time alone could be a couple hundred milliseconds.

from photosauce.

@saucecontrol
Ok when I warm up i have 117ms that is better than libvips.

In my scenario, I need a console application that gets the file name and size as an argument, and resizes image and saves it.

It is always one image file, so I can't "warm up". Is there any possibility for it to work just like libvips CLI but with full MagicScaler performance? I have no experience with C and net framework applications.

from photosauce.

Any kind of complicated processing in a one-shot .NET app is tricky to optimize because of startup and JIT overhead.

The best option I can offer would be to try using ngen.exe from the .NET SDK to generate and cache native images of the MagicScaler dll and your console app. That could reduce your startup times enough to be comparable, but it's tough to compete with pure native code for short-lived apps.

from photosauce.

@saucecontrol
Thanks, It seems too complicated for me so I'll give it up. Unless you help in how to do it? :)

from photosauce.

😆 I'm afraid I don't have time to work up full instructions today, but I might add something next time I have a documentation day.

from photosauce.