diff options
author | Avi Halachmi (:avih) <avihpit@yahoo.com> | 2023-08-24 13:22:24 +0300 |
---|---|---|
committer | Avi Halachmi (:avih) <avihpit@yahoo.com> | 2023-08-24 13:52:54 +0300 |
commit | 5862b6920d519974c2453529bdfd6832dd06f807 (patch) | |
tree | 7d70f298f1a1199f5ed330fc1d24be180fffdf01 /TODO | |
parent | f4f0515429d8ace3c3314ee0e823205d8044f2ac (diff) | |
download | busybox-w32-5862b6920d519974c2453529bdfd6832dd06f807.tar.gz busybox-w32-5862b6920d519974c2453529bdfd6832dd06f807.tar.bz2 busybox-w32-5862b6920d519974c2453529bdfd6832dd06f807.zip |
win32: UTF8_OUTPUT: speedup for big outputs
With the native Windows console, writeCon_utf8 which converts
a stream of UTF8 into console output is about 1.4x slower for big
unicode writes than the native fwrite (e.g. when the console codepage
is UTF8), which is not too bad.
However, newer versions of conhost are quicker, e.g. OpenConsole.exe
(which is conhost) which ships with the Windows terminal is about 4x
faster than the native conhost in processing (unicode?) input.
And when conhost can process inputs much quicker, it turned out that
fwrite throughput was nearly 3x better than writeCon_utf8.
Luckily, this turned out to be mainly due to the internal 256 wide
chars buffer which writeCon_utf8 uses, and that with 4096 buffer
it becomes only ~ 10% slower than fwrite, which is much better.
However, making the console window very small such that it needs to
spend very little time on rendering, makes it apparent that there's
still a difference - writeCon_utf8 is about 30% slower than fwrite,
but that's still not bad, and that's also an uncommon use case.
So this commit increases the buffer, and also allocates it dynamically
(once) to avoid abusing the stck with additional 8K in one call.
Diffstat (limited to 'TODO')
0 files changed, 0 insertions, 0 deletions