starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Code Health/Deps: Add Fast_IO library and use it #8810

New Issue
Closed
opened 2026-01-31 01:38:32 +00:00 by claunia · 13 comments
claunia commented 2026-01-31 01:38:32 +00:00
Owner
Copy Link

Originally created by @WSLUser on GitHub (Jun 4, 2020).

Description of the new feature/enhancement

fast_io is a C++ general-purpose exception-safe RAII I/O library based on C++ 20 Concepts. It is at least ten times faster than cstdio or iostream.

As this is compatible with stdio, cstdio (which has a pending PR still to replace stdio) and iostreams, simply use it for new code and refactorings to boost the performance of I/O in Windows Terminal even further. This will actually allow us to not use fmt for some things (not sure if the fmt calls that are superseded are actually in use yet). As part of getting C++20 compliant (ref: https://github.com/microsoft/terminal/issues/6251), this library should help get the project there. This is covered under the MIT license so there are no legal issues to worry about.

Proposed technical implementation details (optional)

Go to https://github.com/expnkx/fast_io and simply add the release into dep/ of our project. See the README to get a bunch of performance benchmark comparisons (it's a cross-platform project). There's also a video comparing to some of the fmt stuff. I guess there was some friction between the two project authors: https://www.youtube.com/watch?v=avyIFLuFUQs

Originally created by @WSLUser on GitHub (Jun 4, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # Description of the new feature/enhancement fast_io is a C++ general-purpose exception-safe RAII I/O library based on C++ 20 Concepts. It is at least ten times faster than cstdio or iostream. <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> As this is compatible with stdio, cstdio (which has a pending PR still to replace stdio) and iostreams, simply use it for new code and refactorings to boost the performance of I/O in Windows Terminal even further. This will actually allow us to not use fmt for some things (not sure if the fmt calls that are superseded are actually in use yet). As part of getting C++20 compliant (ref: https://github.com/microsoft/terminal/issues/6251), this library should help get the project there. This is covered under the MIT license so there are no legal issues to worry about. # Proposed technical implementation details (optional) Go to https://github.com/expnkx/fast_io and simply add the release into dep/ of our project. See the README to get a bunch of performance benchmark comparisons (it's a cross-platform project). There's also a video comparing to some of the fmt stuff. I guess there was some friction between the two project authors: https://www.youtube.com/watch?v=avyIFLuFUQs <!-- A clear and concise description of what you want to happen. -->
claunia added the Issue-TaskResolution-Won't-FixProduct-MetaArea-Build labels 2026-01-31 01:38:32 +00:00
claunia commented 2026-01-31 01:38:34 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 5, 2020):

I'd love to see a perf trace that highlights a place in the codebase where replacing whatever we're currently doing with fast_io would remove some sort of bottleneck.

Would we need to move the entire solution over to C++20 to be able to use this? I was under the impression that C++20 support wasn't quite finished yet. I know that we'll want to use that when we can, but I'd want to make sure the compiler is stable enough first.

@zadjii-msft commented on GitHub (Jun 5, 2020): I'd love to see a perf trace that highlights a place in the codebase where replacing whatever we're currently doing with fast_io would remove some sort of bottleneck. Would we need to move the entire solution over to C++20 to be able to use this? I was under the impression that C++20 support wasn't quite finished yet. I know that we'll _want_ to use that when we can, but I'd want to make sure the compiler is stable enough first.
claunia commented 2026-01-31 01:38:34 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Jun 5, 2020):

The compiler should be fine as long we're running the latest supported. It illustrates the version tested with one of the benchmark tables for MSVC. I highly suggest looking at the README. The benchmarks include comparing specific std/fmt calls.

Platform Windows MSVC 19.26.28805
Method Output time Input time Comment
stdio.h(fprintf/fscanf) 1.5353597s 1.4157233s  
fstream 3.6350262s 3.8420339s  
fstream with rdbuf.sputc trick 3.3735902s 3.8145566s  
fast_io::i/obuf_file 0.0631433s 0.1030554s  
fast_io::i/obuf_file_mutex 0.2190659s 0.2485886s thread safe
std::to_chars+obuf_file 0.1641641s Meaningless  
std::to_chars+ofstream 0.5461922s Meaningless  
fast_io::c_file_unlocked 0.1102575s 0.2399757s I hacked Universal CRT's FILE* implementation
fast_io::c_file 0.2034755s 0.2621148s Thread Safe. I hacked UCRT's FILE* implementation
fast_io::filebuf_file 0.126661s 0.2378803s I hacked MSVC STL's streambuf/filebuf implementation
@WSLUser commented on GitHub (Jun 5, 2020): The compiler should be fine as long we're running the latest supported. It illustrates the version tested with one of the benchmark tables for MSVC. I highly suggest looking at the README. The benchmarks include comparing specific std/fmt calls. Platform | Windows | MSVC 19.26.28805 -- | -- | -- Method | Output time | Input time | Comment -- | -- | -- | -- stdio.h(fprintf/fscanf) | 1.5353597s | 1.4157233s |   fstream | 3.6350262s | 3.8420339s |   fstream with rdbuf.sputc trick | 3.3735902s | 3.8145566s |   fast_io::i/obuf_file | 0.0631433s | 0.1030554s |   fast_io::i/obuf_file_mutex | 0.2190659s | 0.2485886s | thread safe std::to_chars+obuf_file | 0.1641641s | Meaningless |   std::to_chars+ofstream | 0.5461922s | Meaningless |   fast_io::c_file_unlocked | 0.1102575s | 0.2399757s | I hacked Universal CRT's FILE* implementation fast_io::c_file | 0.2034755s | 0.2621148s | Thread Safe. I hacked UCRT's FILE* implementation fast_io::filebuf_file | 0.126661s | 0.2378803s | I hacked MSVC STL's streambuf/filebuf implementation
claunia commented 2026-01-31 01:38:35 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Jun 5, 2020):

It has more things it can fix up with gcc than MSVC, something I think we should go to eventually.

@WSLUser commented on GitHub (Jun 5, 2020): It has more things it can fix up with gcc than MSVC, something I think we should go to eventually.
claunia commented 2026-01-31 01:38:35 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 5, 2020):

Well sure, but are there any hot paths in our codebase currently that are using std::to_chars, fprintf, fstream?

@zadjii-msft commented on GitHub (Jun 5, 2020): Well sure, but are there any hot paths in our codebase currently that are using `std::to_chars`, `fprintf`, `fstream`?
claunia commented 2026-01-31 01:38:35 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Jun 5, 2020):

I was hoping @skyline75489 could take a look since he's the perf guy who is more likely to find a place where this could be used or if this is completely not applicable to us at all but I will do some preliminary checking.

@WSLUser commented on GitHub (Jun 5, 2020): I was hoping @skyline75489 could take a look since he's the perf guy who is more likely to find a place where this could be used or if this is completely not applicable to us at all but I will do some preliminary checking.
claunia commented 2026-01-31 01:38:36 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Jun 5, 2020):

Based on my previous experience, most CPU time was used on rendering side. I’m not quite the conpty guy. But I’m getting there. Once I get to know more about conpty, maybe I’ll find a place for it.

@skyline75489 commented on GitHub (Jun 5, 2020): Based on my previous experience, most CPU time was used on rendering side. I’m not quite the conpty guy. But I’m getting there. Once I get to know more about conpty, maybe I’ll find a place for it.
claunia commented 2026-01-31 01:38:36 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Jun 5, 2020):

It would tremendously help if there was a way to quickly search the codebase for these call strings. If anyone knows a way to do so, I'd appreciate the tip.

@WSLUser commented on GitHub (Jun 5, 2020): It would tremendously help if there was a way to quickly search the codebase for these call strings. If anyone knows a way to do so, I'd appreciate the tip.
claunia commented 2026-01-31 01:38:36 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Jun 5, 2020):

So far it appears we aren't doing everything we can for optimizing our C++ code. See https://www.thegeekstuff.com/2015/01/c-cpp-code-optimization/. There have been tweaks and tuning but some things like https://github.com/microsoft/terminal/pull/5152 aren't in place yet, which would help to some limited degree. Realistically, every optimization we do won't add much on it's own, it's when combined with other optimizations, that it starts to become noticeable. It's probably the reason why issues like https://github.com/microsoft/terminal/issues/5963 and https://github.com/microsoft/terminal/issues/3075 exist. So instead of relying on older optimization techniques that would need refactoring for this header-only library, we should just use this library to start with. Fortunately this means my issue is valid exactly as is. It will just be part of a larger issue that needs to be created for optimizing our C++ code.

@WSLUser commented on GitHub (Jun 5, 2020): So far it appears we aren't doing everything we can for optimizing our C++ code. See https://www.thegeekstuff.com/2015/01/c-cpp-code-optimization/. There have been tweaks and tuning but some things like https://github.com/microsoft/terminal/pull/5152 aren't in place yet, which would help to some limited degree. Realistically, every optimization we do won't add much on it's own, it's when combined with other optimizations, that it starts to become noticeable. It's probably the reason why issues like https://github.com/microsoft/terminal/issues/5963 and https://github.com/microsoft/terminal/issues/3075 exist. So instead of relying on older optimization techniques that would need refactoring for this header-only library, we should just use this library to start with. Fortunately this means my issue is valid exactly as is. It will just be part of a larger issue that needs to be created for optimizing our C++ code.
claunia commented 2026-01-31 01:38:36 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 5, 2020):

I know in VSCode and Sublime, you can typically just open up the entire repo directory, and search in all the files:

image
For me, this is bound to ctrl+shift+f

Also, it's almost certainly not the reason #5963 exists. We're pretty confident that's because fundamentally the console isn't just a pair of pipes we can read/write to/from. There's the whole console driver that shuttles API calls between the client and the console host, and that's probably slower than just writing a pipe.

@zadjii-msft commented on GitHub (Jun 5, 2020): I know in VSCode and Sublime, you can typically just open up the entire repo directory, and search in all the files: ![image](https://user-images.githubusercontent.com/18356694/83885131-8bca6f00-a70b-11ea-80d6-1e999fb4e9c0.png) For me, this is bound to <kbd>ctrl+shift+f</kbd> <hr> Also, it's almost certainly not the reason #5963 exists. We're pretty confident that's because fundamentally the console isn't just a pair of pipes we can read/write to/from. There's the whole console driver that shuttles API calls between the client and the console host, and that's probably slower than just writing a pipe.
claunia commented 2026-01-31 01:38:37 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Jun 5, 2020):

Indeed, that would be another one of those tweaks that helps. I wonder though if when writing a pipe, you could take advantage of fast_io to boost performance of the pipe writing.

@WSLUser commented on GitHub (Jun 5, 2020): Indeed, that would be another one of those tweaks that helps. I wonder though if when writing a pipe, you could take advantage of fast_io to boost performance of the pipe writing.
claunia commented 2026-01-31 01:38:37 +00:00
Author
Owner
Copy Link

@vitaut commented on GitHub (Jun 29, 2020):

I guess there was some friction between the two project authors

The {fmt} author here. To clarify the friction part: I called out obviously false performance claims made by the fast_io author (let's say they are using somewhat biased benchmarking methodology =)) and severe code bloat issues with fast_io which unfortunately were ignored. A note of warning: the person is known for their erratic behavior (see e.g. https://github.com/expnkx/fast_io/issues/8) and spamming open-source repositories (https://github.com/isocpp/CppCoreGuidelines/issues/1584) including my own with non-sensical claims.

@vitaut commented on GitHub (Jun 29, 2020): > I guess there was some friction between the two project authors The {fmt} author here. To clarify the friction part: I called out obviously false performance claims made by the fast_io author (let's say they are using somewhat biased benchmarking methodology =)) and severe code bloat issues with fast_io which unfortunately were ignored. A note of warning: the person is known for their erratic behavior (see e.g. https://github.com/expnkx/fast_io/issues/8) and spamming open-source repositories (https://github.com/isocpp/CppCoreGuidelines/issues/1584) including my own with non-sensical claims.
claunia commented 2026-01-31 01:38:37 +00:00
Author
Owner
Copy Link

@vitaut commented on GitHub (Jun 29, 2020):

BTW the main perf advantage of fast_io is avoiding synchronization when writing to a stream which can be done in simpler ways without pulling in the whole library.

@vitaut commented on GitHub (Jun 29, 2020): BTW the main perf advantage of fast_io is avoiding synchronization when writing to a stream which can be done in simpler ways without pulling in the whole library.
claunia commented 2026-01-31 01:38:37 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jul 14, 2020):

I've been pouring over perf traces on things like the PTY for weeks now and nothing in particular stands out as something that needs a specific fast-io library to achieve. I'm also concerned on the testimonials provided by @vitaut. That's not generally the behavior of a library author that meshes with our Microsoft Code of Conduct.

As such, I'm going to close this at this time. Thanks for the idea @WSLUser. If you see specific hot perf routes, please let me know with a trace.

@miniksa commented on GitHub (Jul 14, 2020): I've been pouring over perf traces on things like the PTY for weeks now and nothing in particular stands out as something that needs a specific fast-io library to achieve. I'm also concerned on the testimonials provided by @vitaut. That's not generally the behavior of a library author that meshes with our Microsoft Code of Conduct. As such, I'm going to close this at this time. Thanks for the idea @WSLUser. If you see specific hot perf routes, please let me know with a trace.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Build Issue-Task Product-Meta Resolution-Won't-Fix
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#8810
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?