fast_io

fast_io is a C++20 input/output library that provides exceptional speed and is designed to replace the commonly used <iostream> and <cstdio> libraries. It is a header-only library and is licensed under the MIT license, making it easy to include in any project. However, it requires a C++20 compiler that supports concepts.

The original repository for fast_io has been archived due to git bloat over time, but older commits can still be found there. old commits were here.

Examples

Print to stdout

#include <fast_io.h>

int main() {
	print("Hello, fast_io world!\n");
}

Memory map file

#include <fast_io.h>

int main() {
	fast_io::native_file_loader file_data("text.txt");
	// file_data satisfies std::ranges::contiguous_range
}

Other examples

For other up-to-date examples, please look in the examples/ folder.

Deprecated examples are here but they might not work anymore.

This i18n repo stores the i18n source files.

https://bitbucket.org/ejsvifq_mabmip/fast_io_i18n

F.A.Q.

What does "fast" mean in fast_io?

The term fast in fast_io does not necessarily imply that it is the fastest input/output library available (as it would have been named as fastest_io instead). Instead, the term refers to the fact that fast_io is notably faster than <iostream> and <cstdio> libraries in all cases.

What are the supported platforms, compilers...?

See support.md for a list of supported things and platform specific usage notes.

Other questions?

You can ask questions on the fast_io discord server or QQ group: 801441303.

Documentation

See either https://ewindy.gitee.io/fast_io_rst/index.html or https://gitee.com/qabeowjbtkwb/fast_io/wikis.

Features

• As close to system call as possible.

• Unicode support (UTF-8, UTF-16, UTF-32) + codecvt for GB18030 and UTF-EBCDIC (no libc correctly deals with it)

• RAII for C FILE*, POSIX fd and win32/NT HANDLE

• Interop with <cstdio> and <iostream>

• No easily misused stuff like std::endl

• Static I/O manipulators instead of format strings.

• Optional locale.

• Stateless I/O manipulation.

• Consistent error handling; when available, exceptions as the only error reporting mechanism (no std::error_code, std::system_error or useless bounds checking)

• Freestanding mode.

• Address Sanitizer special code for protecting memory safety issues.

• Dynamic Instrumentation Support

• Supports POSIX iconv. You can use fast_io for your coding conversion.

• Binary serialization for trivially copyable types and standard containers

• Plays well with C++ containers (e.g. std::vector<fast_io::obuf_file> is valid)

• Basic/Lua/Python/etc format (print, scan). No support for C and C++ since they are security hazards.

• Provide APIs to expose the internal implementation of FILE* and C++ streams.

• Native Handle Interface

• Extremely easy to support custom devices

• C and C++ style compile time open mode parsing.

• No traits_type and EOF

• Dynamic Type Support

• Multi Process

• Memory mapping

• debugging IO (optionally with GUI)

• Round-trip floating point algorithm

• Hash algorithms support: intrinsic SHA-1, intrinsic HMAC-SHA1, intrinsic SHA-256, intrinsic HMAC-SHA256, SHA-512, HMAC-SHA512 as well as non crypto hash algorithms, such as Jenkins Hash.

• zlib compression/decompression

• Filesystem

• OpenSSL BIO, Qt QFile, MFC CFile support

Post C++20

1. Module support
2. Coroutine support for async IO
3. Improve and refactor code once Zero-overhead deterministic exceptions are added to the standard

Benchmarks

1. I/O 10M integers

Goal: Print out ten million integers from 0 to 10M to file. Then reopen that file to scan back.

All benchmarks are in benchmarks/0000.10m_size_t/unit.

Notice: I modified libstdc++'s BUFSIZ 1048576 due to BUFSIZ is too small (512 bytes) for MinGW-W64, or it performs horribly.

Rust language is 10x slower than fast_io. + binary bloat and itoa library is still extremely slow and usable for me. It is at least 3x slower than fast_io.

Run the same test on MSVC 19.26.28805.

Run the same test on GCC 11. glibc + libstdc++

You can see fast_io can also boost the performance of existing facilities for 10x! Yes, it can even improve FILE* and fstream's performance for 10x depending on platforms since I use concepts to abstract them all. fmtlib actually slows down I/O performance.

2. Output 10M double in round-trip mode with Ryu algorithm

We only perform this test for MSVC since only msvc's charconv implements it. Yes. fast_io defeats msvc's charconv for over 20% for running the same algorithm.

All benchmarks are in benchmarks/0001.10m_double/charconv.

Run the same test on MSVC 19.26.28805.

3. Raw I/O Performance

All benchmarks are in benchmarks/0014.file_io/file_io.

Output 100000000x "Hello World\n"

Notice: I modified libstdc++'s std::filebuf's BUFSIZ to 1048576 due to BUFSIZ is too small (512 bytes) for MinGW-W64 or it performs horribly.

4. Binary Size Just use the benchmark in benchmarks/0014.file_io/file_io. Dude, you should avoid stream as plague tbh. It is not healthy.

5. Code Convert

Generate 100000000 🚄 emojis by using the program in benchmarks/0020.utf/fill_nc.cc

Benchmarks are in examples/0043.iconv Universal iconv. (UTF-8 to GB18030 as an example) iconv test:

UTF8->UTF16LE

Benchmarks are in examples/0022.utf

iconv test:

UTF8->UTF32LE

Benchmarks are in examples/0022.utf

iconv test:

Credits

The creation and development of this project were made possible thanks to the valuable contributions of various open-source projects. While the code was not copied directly from these projects, I used them as references and re-implemented them to suit the specific purposes of this library. In some cases, integration issues arose that required modifications to the original code. I am grateful to these projects and their developers for their commitment to making their code open and accessible to the wider community.