The total time is the time used doing the actual conversion plus the overhead.

The time for the actual conversion varies depending on options and the image, and we cannot do anything about that. For very small images, it is as low as 10 ms on my machine. For 1MB images, it is around 200 ms.

The overhead consists of detecting available binaries, detecting their versions, ordering them in order to pick the highest version available and creating options. It is pretty constant around 70 ms on my machine when only cwebp-try-supplied-binary-for-os is enabled and around 85 ms when all methods for detecting cwebp binaries are enabled.

There are 4 supplied binaries for linux. If I comment out 3 of them, the overhead is decreased to 25 ms. Now, why does it take so long time detect a supplied binary? It turns out that it is the hash check that is expensive. It takes between 10-20 ms to create the checksum for each binary file.

Now, why not just have 1 supplied binary? The reason is that they have different dependencies. Some builds works on some systems, while others works on others. See #196 and #278.

But actually, some improvement could be made. There is no need to detect the versions of the supplied binaries, as we know what they are supposed to be beforehand. So the hash check could be postponed till right before doing the conversion. In case a cwebp binary is found using one of the other methods, and it is not an older version than the supplied binaries, no hash check will need to be run at all.

Until such optimizations are made, you could try disabling the "cwebp-try-supplied-binary-for-os" option and see if it still works. If it does, you should experience a significant performance gain.

Uh oh!

Conversion with cwebp takes much longer with version 2.3.0+ #285

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions