aboutsummaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorAvi Halachmi (:avih) <avihpit@yahoo.com>2023-08-24 13:22:24 +0300
committerAvi Halachmi (:avih) <avihpit@yahoo.com>2023-08-24 13:52:54 +0300
commit5862b6920d519974c2453529bdfd6832dd06f807 (patch)
tree7d70f298f1a1199f5ed330fc1d24be180fffdf01 /docs
parentf4f0515429d8ace3c3314ee0e823205d8044f2ac (diff)
downloadbusybox-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 'docs')
0 files changed, 0 insertions, 0 deletions