Windows decoding performance #146

New Issue

claunia · 2026-01-29T20:38:32Z

claunia commented

2026-01-29 20:38:32 +00:00

Originally created by @eustas on GitHub (Nov 22, 2016).

It seems that windows brotli binary is 1.5x slower than linux one. Even if compiled with mingw gcc 5.4.

I run it under Wine, but I am almost sure this can't be a problem source.

Any ideas, what could cause slowness?

Originally created by @eustas on GitHub (Nov 22, 2016). It seems that windows brotli binary is 1.5x slower than linux one. Even if compiled with mingw gcc 5.4. I run it under Wine, but I am almost sure this can't be a problem source. Any ideas, what could cause slowness?

claunia closed this issue

2026-01-29 20:38:33 +00:00

claunia commented

2026-01-29 20:38:34 +00:00

@eustas commented on GitHub (Nov 22, 2016):

Found the problem: it is IO!
If I comment out fwrite, then speed difference is less than 10%. Going to make a serie of pure in-memory tests and report back.

@eustas commented on GitHub (Nov 22, 2016): Found the problem: it is IO! If I comment out fwrite, then speed difference is less than 10%. Going to make a serie of pure in-memory tests and report back.

claunia commented

2026-01-29 20:38:36 +00:00

@eustas commented on GitHub (Nov 23, 2016):

Completed some measurements.
Corpora:

wiki - enwik8, compression level 9
geo - non human-readable data, compression level 6
html - various HTML pages, compression level 11

Binaries:

linux-mingw - mingw gcc 4.8.2 under Ubuntu
old-linux - gcc 4.8.4
linux - gcc 5.2.0
win32 - MSVC 2015, default Premake5 generated project
win64 - MSVC 2015, same as above, but switched to x64 platform
win-mingw - mingw gcc 5.4.0

Baseline is linux; other lines - percentage of speed, relative to linux speed for the same corpus.
Windows binaries are tested under Wine.

Binary	`wiki`	`geo`	`html`
`linux-mingw`	92.2%	90.6%	83.85%
`old-linux`	97.6%	96.0%	97.6%
`linux`	100.0%	100.0%	100.0%
`win32`	58.3%	61.2%	64.2%
`win64`	76.3%	67.3%	77.2%
`win-mingw`	95.1%	94.2%	87.7%

Conclusions:

32-bit binaries are not reasonable; Premake5 configuration should be modified to work out of the box
MSVC binaries are considerably slower; need to make further investigations
older gcc produces 3-4% slower binaries
modern mingw binaries are fair except for html case; perhaps there is something that adds overhead for literal context modeling on Windows (calling convention / register starvation?)

Bottom line:

are there good profilers for Windows binaries?; under Linux I use linux-tools perf; but it doesn't work for binaries under Wine
any ideas how to define IS_CONSTANT macros for MSVC?

@eustas commented on GitHub (Nov 23, 2016): Completed some measurements. Corpora: * `wiki` - enwik8, compression level 9 * `geo` - non human-readable data, compression level 6 * `html` - various HTML pages, compression level 11 Binaries: * `linux-mingw` - mingw gcc 4.8.2 under Ubuntu * `old-linux` - gcc 4.8.4 * `linux` - gcc 5.2.0 * `win32` - MSVC 2015, default Premake5 generated project * `win64` - MSVC 2015, same as above, but switched to x64 platform * `win-mingw` - mingw gcc 5.4.0 Baseline is `linux`; other lines - percentage of speed, relative to `linux` speed for the same corpus. Windows binaries are tested under Wine. | Binary | `wiki` | `geo` | `html` | |---|--:|--:|--:| | `linux-mingw` | 92.2% | 90.6% | 83.85% | | `old-linux` | 97.6% | 96.0% | 97.6% | | `linux` | 100.0% | 100.0% | 100.0% | | `win32` | 58.3% | 61.2% | 64.2% | | `win64` | 76.3% | 67.3% | 77.2% | | `win-mingw` | 95.1% | 94.2% | 87.7% | Conclusions: * 32-bit binaries are not reasonable; Premake5 configuration should be modified to work out of the box * MSVC binaries are considerably slower; need to make further investigations * older gcc produces 3-4% slower binaries * modern mingw binaries are fair except for `html` case; perhaps there is something that adds overhead for literal context modeling on Windows (calling convention / register starvation?) Bottom line: * are there good profilers for Windows binaries?; under Linux I use `linux-tools` `perf`; but it doesn't work for binaries under Wine * any ideas how to define `IS_CONSTANT` macros for MSVC?

claunia commented

2026-01-29 20:38:38 +00:00

@eustas commented on GitHub (Nov 23, 2016):

Disabling all compiler specific tricks doesn't hurt Linux/gcc performance more than 5% -> PREDICT_X / IS_CONSTANT seems to be a wrong trail.

MSVC PGO is simply no-op.

@eustas commented on GitHub (Nov 23, 2016): Disabling all compiler specific tricks doesn't hurt Linux/gcc performance more than 5% -> PREDICT_X / IS_CONSTANT seems to be a wrong trail. MSVC PGO is simply no-op.

claunia commented

2026-01-29 20:38:41 +00:00

@eustas commented on GitHub (Nov 25, 2016):

Compiled with gcc 6.2.1 and mingw-gcc 6.2.1 with -fpic and fascall convention for internal functions...
Now disassembly looks almost the same (excluding aligning "nop" style and register scheduling)... but windows binary is still slower (under Wine). Pure mystery!

@eustas commented on GitHub (Nov 25, 2016): Compiled with gcc 6.2.1 and mingw-gcc 6.2.1 with `-fpic` and fascall convention for internal functions... Now disassembly looks almost the same (excluding aligning "nop" style and register scheduling)... but windows binary is still slower (under Wine). Pure mystery!

claunia commented

2026-01-29 20:38:42 +00:00

@eustas commented on GitHub (Jun 1, 2017):

Only CLI is hurt by IO; closing this issue, due to the lack of interest. Feel free to reopen it.

@eustas commented on GitHub (Jun 1, 2017): Only CLI is hurt by IO; closing this issue, due to the lack of interest. Feel free to reopen it.

claunia referenced this issue

2026-01-29 20:50:43 +00:00

[PR #146] [MERGED] update brotli encoder with latest improvements #756

Sign in to join this conversation.