Issue 54 in webp: cwebp is slow

[pascal.massimino@gmail.com via Monorail]

Updates:
Status: Fixed

Comment #8 on issue 54 by pascal.m...@gmail.com: cwebp is slow
https://bugs.chromium.org/p/webp/issues/detail?id=54#c8

Out of curiosity, re-did the test on my Mac. We're down to 3.3s with
libwebp 0.5.0.
Will be closing the bug for now. We can track encoding speed more regularly
on the mailing-list.

Dimension: 11158 x 2156
Output: 4725026 bytes Y-U-V-All-PSNR 36.98 42.39 44.02 38.24 dB
block count: intra4: 88947
intra16: 5283 (-> 5.61%)
skipped block: 761 (0.81%)
bytes used: header: 536 (0.0%)
mode-partition: 505952 (10.7%)
Residuals bytes |segment 1|segment 2|segment 3|segment 4| total
macroblocks: | 15%| 30%| 34%| 19%| 94230
quantizer: | 36 | 29 | 23 | 15 |
filter level: | 11 | 6 | 5 | 7 |

real 0m3.430s
user 0m3.342s
sys 0m0.070s


--
You received this message because:
1. The project was configured to send all issue notifications to this
address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

[fbarchard@google.com via Monorail]

Comment #9 on issue 54 by fbarch...@google.com: cwebp is slow
https://bugs.chromium.org/p/webp/issues/detail?id=54#c9

Re-tested on Windows7 with HP Z620, using prebuilt 0.5.0 binaries:

timex cwebp -q 75 bryce_big.jpg -o bryce_big.webp
Saving file 'bryce_big.webp'
File: bryce_big.jpg
Dimension: 11158 x 2156
Output: 4472094 bytes Y-U-V-All-PSNR 36.84 42.22 43.95 38.11 dB
block count: intra4: 85251
intra16: 8979 (-> 9.53%)
skipped block: 1432 (1.52%)
bytes used: header: 509 (0.0%)
mode-partition: 515490 (11.5%)

Residuals bytes |segment 1|segment 2|segment 3|segment 4| total

intra4-coeffs: | 2526319 | 820986 | 273838 | 53740 | 3674883 (82.2%)
intra16-coeffs: | 2074 | 16260 | 29189 | 14936 | 62459 (1.4%)
chroma coeffs: | 131830 | 49984 | 29030 | 7880 | 218724 (4.9%)
macroblocks: | 53%| 26%| 14%| 5%| 94230
quantizer: | 30 | 24 | 17 | 15 |
filter level: | 4 | 0 | 0 | 0 |
------------------+---------+---------+---------+---------+-----------------
segments total: | 2660223 | 887230 | 332057 | 76556 | 3956066 (88.5%)
TIMEX 11824.00 ms (11.82 seconds), cwebp -q 75 bryce_big.jpg -o
bryce_big.webp

3.44x slower than Mac?
Other codecs are 1 to 2 seconds, so 11.8 seconds is nearly an order of
magnitude slower than alternatives.

Seems like there an issue with Windows performance?

[pascal.massimino@gmail.com via Monorail]

Comment #10 on issue 54 by pascal.m...@gmail.com: cwebp is slow
https://bugs.chromium.org/p/webp/issues/detail?id=54#c10

your output is different (4472094 vs 4725026 bytes).
This shouldn't happen, unless you linked against the wrong libraries (*or*
used a different jpg decoding library).

[fbarchard@google.com via Monorail]

Comment #11 on issue 54 by fbarch...@google.com: cwebp is slow
https://bugs.chromium.org/p/webp/issues/detail?id=54#c11

good catch... I had old version in my path.
down to 5.38 seconds.

c:\work>timex c:\libwebp-0.5.0-windows-x86\bin\\cwebp.exe -q 75

bryce_big.jpg -o bryce_big.webp
Saving file 'bryce_big.webp'
File: bryce_big.jpg
Dimension: 11158 x 2156

Output: 4681758 bytes Y-U-V-All-PSNR 36.98 42.66 44.25 38.27 dB
block count: intra4: 88047
intra16: 6183 (-> 6.56%)
skipped block: 903 (0.96%)
bytes used: header: 535 (0.0%)
mode-partition: 503170 (10.7%)

Residuals bytes |segment 1|segment 2|segment 3|segment 4| total

macroblocks: | 15%| 30%| 34%| 19%| 94230

quantizer: | 36 | 29 | 23 | 16 |
filter level: | 11 | 6 | 5 | 11 |
TIMEX 5385.00 ms (5.38 seconds),
c:\libwebp-0.5.0-windows-x86\bin\\cwebp.exe -q 75 bryce_big.jpg -o
bryce_big.webp

My current Z620 (Sandy Bridge Xeon) is a faster machine than when I first
reported it on a Z600, but thats at 2.19x faster than the one I had in my
path.
size/quality doesnt exactly match your test? different command line?

5.38s on Windows vs 3.43 on Mac is 1.56x slower?
I'm using prebuilt Windows binaries from the webp site, but assume they
were built with Visual C 32 bit?
Is the code optimized for Windows 32 bit?

[jzern@google.com via Monorail]

Comment #12 on issue 54 by jz...@google.com: cwebp is slow
https://bugs.chromium.org/p/webp/issues/detail?id=54#c12

cwebp -v reports the time to encode, which is what was probably quoted for
the Mac. I see ~4.1s/3.4s on my z620 for x86/x64.

[Pascal Massimino]

timing sounds coherent to me. Windows might be slower because of the jpeg-decoding time being included. Or just because it's another machine/hardware. But yes, SSE2 optims are enabled on Windows.

As for the size difference, i'd say it's because of jpeg decoding library used. You should cross-check with using a PNG or WebP input to cwebp. This one should absolutely produce the exact same output on all platforms!

You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
To post to this group, send email to webp-d...@webmproject.org.
Visit this group at https://groups.google.com/a/webmproject.org/group/webp-discuss/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

[fbarchard@google.com via Monorail]

Comment #13 on issue 54 by fbarch...@google.com: cwebp is slow
https://bugs.chromium.org/p/webp/issues/detail?id=54#c13

With -v I see 5.2s on Windows. So there seems to be a performance
difference with the Visual C (32 bit?) build:

c:\work>timex c:\libwebp-0.5.0-windows-x86\bin\\cwebp.exe -v -q 75
bryce_big.jpg -o bryce_big.webp
Time to read input: 0.307s
Saving file 'bryce_big.webp'
Time to encode picture: 5.215s

File: bryce_big.jpg
Dimension: 11158 x 2156
Output: 4681758 bytes Y-U-V-All-PSNR 36.98 42.66 44.25 38.27 dB
block count: intra4: 88047
intra16: 6183 (-> 6.56%)
skipped block: 903 (0.96%)
bytes used: header: 535 (0.0%)
mode-partition: 503170 (10.7%)
Residuals bytes |segment 1|segment 2|segment 3|segment 4| total
macroblocks: | 15%| 30%| 34%| 19%| 94230
quantizer: | 36 | 29 | 23 | 16 |
filter level: | 11 | 6 | 5 | 11 |

TIMEX 5707.00 ms (5.71 seconds),
c:\libwebp-0.5.0-windows-x86\bin\\cwebp.exe -v -q 75 bryce_big.jpg -o
bryce_big.webp

For comparison ffmpeg on same Z620 produces:

png is 3.36 seconds
timex ffmpeg -y -i bryce_big.jpg bryce_big.png
TIMEX 3362.00 ms (3.36 seconds), ffmpeg -y -i bryce_big.jpg bryce_big.png

jpeg is 1.11 seconds
timex ffmpeg -y -i bryce_big.jpg bryce_big_new.jpg
TIMEX 1106.00 ms (1.11 seconds), ffmpeg -y -i bryce_big.jpg
bryce_big_new.jpg

gif is 1.15
TIMEX 1150.00 ms (1.15 seconds), ffmpeg -y -i bryce_big.jpg
bryce_big_new.gif

If you're having issues with Visual C code quality, consider a (prebuilt)
clangcl build which should be exactly the same speed as mac/linux.