feat: support benchmarking vips processor #44
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background
GdkPixbuf-based image processing can take over 1GB of memory for processing a single high-resolution photo. We've decided to introduce another processor, hoping that it'll improve Morandi's memory profile and performance.
Problems
Benchmarking scripts only supported pixbuf processor
Solution
Morandi.process
inbin/process-single
script - it adds support for vips processor and simplifies the codevips
processor to the benchmarking list inbin/benchmark-all
scriptNotes
I've noticed that
vips
outputs noticeably bigger (in terms of storage space) images, so I've also includedoutput_size_mb
in benchmarking resultsExample benchmark
Observations
vips
is typically lower than bypixbuf
; the difference gets very significant (eg 150MB vs 2.5GB RAM) for high-resolution images; that's expected, as pixbuf loads entire image to memory, while vips processes in chunksvips
is noticeably higher thanpixbuf
's; that can be controlled with concurrency level, but impacts rendering time; in order to make the time comparable between vips and pixbuf, vips concurrency has to be at least 2vips
is roughly 10-50% higher thanpixbuf
's; I don't know the exact cause, I'd guess some implementation detail when saving; the size difference is apparent even on no-op read->writeRaw benchmark results