-
-
Notifications
You must be signed in to change notification settings - Fork 878
Lossless WebP encoder allocates A LOT #2934
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
Comments
Sounds like |
I've made the changes locally and run benchmarks. Here are the results. Current version
PixOrCopy -> struct
PixOrCopy -> struct, Vp8LEncoder + allocator
The first change reduced the allocated memory by half and also noticeably increased encoder performance. The second change reduced the allocated memory even more, but shifted performance a little back. @antonfirsov Any thoughts? |
I didn't expect significant speed difference from the changes, part of the differences we see could be just noise. The allocation improvements make the change absolutely worthy. Are you interested opening a PR? |
Yep. I'll open a PR. |
Uh oh!
There was an error while loading. Please reload this page.
Prerequisites
DEBUG
andRELEASE
modeImageSharp version
3.1.8
Environment (Operating system, version and so on)
Windows 11 with latest updates
.NET Framework version
.NET 9
Description
Lossless WebP encoder allocates both a lot of small object and also a few big chunks, which are NOT reused.
It is about 500 K objects and 200-300 MB total memory to encode single UWQHD (3440x1440) image.
It leads to very high pressure on GC. Especially, if there are many images to process.
My encoding settings are probably the lowest for lossless saving:
I found the following hot paths (for one image):


PixOrCopy.CreateLiteral
produces TONS of small objects.Vp8LEncoder
's constructor may not look that scary, but let's sequentially encode 10 images:As you can see, those big chunks are not reused in the future.
I tried to provide a custom memory allocator. It didn't help.
I suppose the allocator is totally ignored there.
Fixing these two moments should greatly accelerate the WebP encoder:
PixOrCopy.CreateLiteral
problem is probably the hardest one as it requires changing of data structures.Vp8LEncoder
should be much easier.Steps to Reproduce
Just encode an image with performance profiler and object allocation tracking.
The text was updated successfully, but these errors were encountered: