Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved jpeg encoding benchmarks #2051

Merged
merged 5 commits into from
Mar 9, 2022

Conversation

br3aker
Copy link
Contributor

@br3aker br3aker commented Mar 9, 2022

Prerequisites

  • I have written a descriptive pull-request title
  • I have verified that there are no overlapping pull-requests open
  • I have verified that I am following the existing coding patterns and practice as demonstrated in the repository. These follow strict Stylecop rules 👮.
  • I have provided test coverage for my change (where applicable)

Description

Based on discussion from #2039. I've split jpeg encoding benchmark into ImageSharp-only benchmark with all supported color types and 'cross-codec' which compares ImageSharp with other codec (only SkiaSharp currently as System.Drawing is unreliable on Linux).

I've also deleted multi-image benchmark as new benchmarks can be used via replacing filename from const string to string with Params attribute.

Ideally, we would want to create a encode-decode benchmark as it's would be a lot easier to trace and compare to something like MagicScaler as its decoding is tighly coupled with encoding.

Decode-Resize-Encode benchmark would also be helpful and I'd implement it during jpeg dct scaling PR somewhere in the future - no point implementing it now.

Comment on lines +75 to +88
| Method | TargetColorSpace | Quality | Mean | Error | StdDev |
|---------- |----------------- |-------- |----------:|----------:|----------:|
| Benchmark | Luminance | 75 | 7.055 ms | 0.1411 ms | 0.3297 ms |
| Benchmark | Rgb | 75 | 12.139 ms | 0.0645 ms | 0.0538 ms |
| Benchmark | YCbCrRatio420 | 75 | 6.463 ms | 0.0282 ms | 0.0235 ms |
| Benchmark | YCbCrRatio444 | 75 | 8.616 ms | 0.0422 ms | 0.0374 ms |
| Benchmark | Luminance | 90 | 7.011 ms | 0.0361 ms | 0.0301 ms |
| Benchmark | Rgb | 90 | 13.119 ms | 0.0947 ms | 0.0886 ms |
| Benchmark | YCbCrRatio420 | 90 | 6.786 ms | 0.0328 ms | 0.0274 ms |
| Benchmark | YCbCrRatio444 | 90 | 8.672 ms | 0.0772 ms | 0.0722 ms |
| Benchmark | Luminance | 100 | 9.554 ms | 0.1211 ms | 0.1012 ms |
| Benchmark | Rgb | 100 | 19.475 ms | 0.1080 ms | 0.0958 ms |
| Benchmark | YCbCrRatio420 | 100 | 10.146 ms | 0.0585 ms | 0.0519 ms |
| Benchmark | YCbCrRatio444 | 100 | 15.317 ms | 0.0709 ms | 0.0592 ms |
Copy link
Contributor Author

@br3aker br3aker Mar 9, 2022

Choose a reason for hiding this comment

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

Luminance encoding has same (or even worse) performance as YCbCr 4:2:0 because Rgb24 -> L8 conversion uses scalar code. It would be a lot faster if user decodes image into L8 pixel type.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah theres definitely optimisation opportunity there.

Copy link
Member

@JimBobSquarePants JimBobSquarePants left a comment

Choose a reason for hiding this comment

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

Thanks for this, looks great.

@JimBobSquarePants JimBobSquarePants merged commit 823e785 into SixLabors:main Mar 9, 2022
@br3aker br3aker deleted the dp/jpeg-benchmark branch March 9, 2022 12:45
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.

2 participants