-
Notifications
You must be signed in to change notification settings - Fork 42
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
Benchmark common::Frame::from_rgba_speed
#113
Comments
I've been working on a personal project using This is what I have so far for benching - it just uses PNGs in the samples directory for the input. |
In #110, support was added to bypass the NeuQuant algorithm when the color count was
<= 256
so that it could fit in a palette without quantization. The implementation is very straightforward and clear but there may be possible performance improvements. It'd be good to have a benchmark to test changes in this function since it's in the main path for encodingFrame
s.The following are preliminary thoughts on the topic. They may not be faster than the current implementation.
At the cost of making the logic more complex, there may be a way to reduce allocation and hash calculations in palette creation. A
HashSet
is used, collected into aVec
, and then theVec
is built into aHashMap
. TheHashMap
and palette indexing could be built from the start but manual bookkeeping would need to be introduced for indexing.image-gif/src/common.rs
Lines 220 to 255 in 5410cb3
It's not clear if this
sort
is necessary. Maybe it can be made into asort_unstable
or removed altogether.image-gif/src/common.rs
Lines 239 to 243 in 5410cb3
Original discussion started in #111 (comment)
The text was updated successfully, but these errors were encountered: