首页>编程相关>C/C++
下载

fast_io

Fast_io是C ++ 20输入/输出库，可提供出色的速度，旨在替换常用的<iostream>和<cstdio>库。它是一个仅限标题库，已获得MIT许可证的许可，使其易于在任何项目中纳入。但是，它需要一个支持概念的C ++ 20编译器。

随着时间的推移，由于git的膨胀，Fast_io的原始存储库已被存档，但是在那里仍然可以找到较旧的提交。旧提交在这里。

例子

打印到stdout 

# include < fast_io.h >

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

内存图文件

# include < fast_io.h >

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

其他例子

有关其他最新示例，请查看examples/文件夹。

弃用的例子在这里，但它们可能不再起作用。

此I18N存储库存储I18N源文件。

https://bitbucket.org/ejsvifq_mabmip/fast_io_i18n

常问问题

fast_io中的“快速”是什么意思？

fast_io中的fast不一定意味着它是可用的最快输入/输出库（因为它将被称为fastest_io ）。相反，该术语是指在所有情况下fast_io的速度明显快于<iostream>和<cstdio>库。

哪些受支持的平台，编译器...？

有关支持的事物列表和平台特定的用法说明，请参见support.md。

其他问题？

您可以在Fast_io Discord Server或QQ组上询问问题： 801441303 。

文档

请参阅https://ewindy.gitee.io/fast_io_rst/index.html或https://gitee.com/qabeowjbtkwb/fast_io/wikis。

特征

  • 尽可能接近系统调用。

  • Unicode支持（UTF-8，UTF-16，UTF-32） + gb18030和utf-ebcdic（无LIBC正确处理）

  • raii用于c FILE* ，posix fd和win32/nt HANDLE

  • 与<cstdio>和<iostream>互动

  • 没有像std::endl这样的轻松滥用的东西

  • 静态I/O操纵器而不是格式字符串。

  • 可选区域。

  • 无状态的I/O操纵。

  • 一致的错误处理；如果有的话，例外是唯一的错误报告机制（无std::error_code ， std::system_error或无用的界限检查）

  • 独立模式。

  • 地址消毒剂特殊代码，以保护记忆安全问题。

  • 动态仪器支持

  • 支持POSIX ICONV。您可以将FAST_IO用于编码转换。

  • 二进制序列化，用于微不足道的类型和标准容器

  • 使用C ++容器效果很好（例如std::vector<fast_io::obuf_file>有效）

  • basic/lua/python/etc格式（打印，扫描）。由于它们是安全危害，因此不支持C和C ++。

  • 提供API，以揭示FILE*和C ++流的内部实现。

  • 本机句柄接口

  • 非常易于支持自定义设备

  • C和C ++样式编译时间打开模式解析。

  • 没有traits_type和EOF

  • 动态类型支持

  • 多过程

  • 内存映射

  • 调试io（可选为GUI）

  • 往返浮点算法

  • 哈希算法支持：内在的SHA-1，内在的HMAC-SHA1，内在的SHA-256，内在的HMAC-SHA256，SHA-512，HMAC-SHA512以及非加密携带算法，例如Jenkins Hash。

  • Zlib压缩/减压

  • 文件系统

  • OpenSSL BIO，QT QFILE，MFC CFILE支持

帖子C ++ 20

  1. 模块支持
  2. Coroutine支持异步IO
  3. 改进和重构代码一旦将零交叉确定性异常添加到标准

基准

  1. I/O 10m整数

目标：将一千万个整数从0到1000万打印到文件。然后重新打开该文件以扫描。

所有基准分配在基准/0000.10M_SIZE_T/单元中。

注意：我修改了由于Bufsiz而导致的libstdc ++的bufsiz 1048576，对于mingw-w64来说太小（512个字节），或者表现可怕。

平台视窗MingW-W64 GCC 11.0.0 MSVCRT+ LIBSTDC ++
方法输出时间输入时间评论
stdio.h（fprintf/fscanf） 2.412987 5.607791
Fstream 0.462012S 1.192S
fstream with rdbuf.sputc trick 0.33895 1.170173
fast_io :: i/obuf_file 0.04903 0.080996S
fast_io :: i/obuf_file_mutex 0.146064S 0.113155S线程安全
c_locale_i/obuf_file（“ c”） 0.065988 0.086012S充满语言环境的“ C”
c_locale_i/obuf_file本地0.153995S充满语言环境“”
fmt :: format_int+obuf_file 0.122999S
fmt :: format_int+ofstream 0.209055
fmt ::格式+ofstream 0.548 FMT使事情变慢
FMT ::打印0.663996S FMT使事情变慢
std :: to_chars+obuf_file 0.12s
std :: to_chars+ofstream 0.192S
fast_io :: c_file_unlocked 0.098999S 0.126003我砍了MSVCRT的文件*实现
fast_io :: c_file 0.298988 0.318001线程安全。我砍了MSVCRT的文件*实现
fast_io :: filebuf_file 0.048999S 0.081我砍了libstdc ++的streambuf/filebuf实现
fast_io :: iobuf_utf8_file_char16 0.124 0.112001带有SSE的UTF-16 => UTF-8
fast_io :: iobuf_utf8_file_char32 0.110999 0.111011S带有SSE的UTF-32 => UTF-8
std :: wofstream 2.64 3.843735S带有std :: Locale codecvt的WOFStream。 TBH极慢。
fast_io :: wfilebuf_io_observer 2.415692 2.497704带有std :: Locale codecvt的WOFStream。这证明Fstream永远无法修复。
生锈语言0.483生锈很慢。 Rust也不涉及语言环境。想想这有多糟糕。
Rust Itoa库0.4.6 > 0.165s我忽略了n部分，以确保没有偏见。

Rust语言比Fast_io慢10倍。 +二进制膨胀和ITOA库仍然非常慢，对我来说是可用的。它至少比Fast_io慢3倍。

在MSVC 19.26.28805上运行相同的测试。

平台视窗MSVC 19.26.28805安装fmtlib浪费我一生的时间
方法输出时间输入时间评论
stdio.h（fprintf/fscanf） 1.5353597 1.4157233S
Fstream 3.6350262S 3.8420339
fstream with rdbuf.sputc trick 3.3735902 3.8145566
fast_io :: i/obuf_file 0.0631433S 0.1030554S
fast_io :: i/obuf_file_mutex 0.2190659 0.2485886线程安全
std :: to_chars+obuf_file 0.1641641S
std :: to_chars+ofstream 0.5461922S
fast_io :: c_file_unlocked 0.1102575S 0.2399757我黑客攻击了环球CRT的文件*实现
fast_io :: c_file 0.2034755 0.2621148线程安全。我砍了ucrt的文件*实现
fast_io :: filebuf_file 0.126661S 0.2378803S我黑客入侵了MSVC STL的StreamBuf/filebuf实现

在GCC 11上进行相同的测试。GLIBC+ LIBSTDC ++

平台Linux GCC 11.0.0 glibc+ libstdc ++
方法输出时间输入时间评论
stdio.h（fprintf/fscanf） 0.532792935S 0.591907111S
fstream with rdbuf.sputc trick 0.318896068 0.429406415S
fast_io :: i/obuf_file 0.050300857S 0.065372395S
fast_io :: i/obuf_file_mutex 0.05290654 0.083040518线程安全
c_locale_i/obuf_file（“ c”） 0.051939052S 0.065820056充满语言环境的“ C”
c_locale_i/obuf_file本地0.162406082S充满语言环境“”
std :: to_chars+obuf_file 0.115453587
fmt :: format_int+obuf_file 0.1183587
fmt :: format_int+ofstream 0.195914384S
fmt ::格式+ofstream 0.633590975S FMT使事情变慢
FMT ::打印0.495270371 FMT使事情变慢
boost :: iostreams 0.400906063S 0.444717051使用Boost iostreams不会使您的代码更快
fast_io :: c_file_unlocked 0.060076723S 0.073299716我砍了Glibc的文件*实现
fast_io :: c_file 0.092490191S 0.104545535S线程安全。我砍了Glibc的文件*实现
fast_io :: filebuf_file 0.052251608 0.06655806我砍了libstdc ++的streambuf/filebuf实现

您可以看到fast_io还可以提高现有设施的10倍性能！是的，它甚至可以根据平台改善文件*和FSTREAM的性能，因为我使用概念将它们全部抽象。 FMTLIB实际上会减慢I/O性能。

  1. 使用RYU算法在往返模式下输出10m双重

我们仅对MSVC执行此测试，因为仅MSVC的CharConv实现了它。是的。 Fast_IO以超过20％的运行而击败了MSVC的CharConv，以运行相同的算法。

所有基准分配在基准/0001.10M_DOUBL/CHARCONV中。

在MSVC 19.26.28805上运行相同的测试。

平台视窗MSVC 19.26.28805
方法输出时间评论
i/obuf_file 0.4653818
charconv + obuf_file 0.6011
  1. 原始I/O性能

所有基准分配在基准/0014.File_io/file_io中。

输出100000000X“ Hello World n”

注意：我修改了libstdc ++的std :: FileBuf的bufsiz至1048576，因为bufsiz对于mingw-w64而言太小（512个字节）或可怕的性能。

平台视窗MingW-W64 GCC 11.0.0 MSVCRT+ LIBSTDC ++
方法输出时间评论
fwrite 2.524001
Fstream 1.013001
fast_io :: obuf_file 0.437998
fast_io :: obuf_file_mutex 1.371线程安全
fast_io :: c_file_unlocked 1.164997我砍了MSVCRT的文件*实现
fast_io :: c_file 3.337945线程安全。我黑客入侵了MSVCRT的文件*实现。需要进一步的优化
fast_io :: filebuf_file 0.467001我入侵了libstdc ++的std :: filebuf实现
平台Linux GCC 11.0.0 glibc+ libstdc ++
方法输出时间评论
fwrite 1.457288317
Fstream 1.249783346
fast_io :: obuf_file 0.494827134
fast_io :: obuf_file_mutex 0.497138826线程安全
fast_io :: c_file_unlocked 0.687976666S我砍了Glibc的文件*实现
fast_io :: c_file 0.910792697S线程安全。我砍了Glibc的文件*实现
fast_io :: filebuf_file 0.526955039我入侵了libstdc ++的std :: filebuf实现
平台视窗MSVC 19.26.28805 UCRT + MSVC STL
方法输出时间评论
fwrite 3.3139122
Fstream 1.7184119S
fast_io :: obuf_file 0.7996034
fast_io :: obuf_file_mutex 2.2949221线程安全。对于MSVC STL来说，STD :: Mutex的速度非常慢。
fast_io :: c_file_unlocked 1.2103924我砍了ucrt的文件*实现
fast_io :: c_file 2.3604295线程安全。我砍了ucrt的文件*实现
fast_io :: filebuf_file 1.2805368我入侵了MSVC STL的STD :: FileBuf实现
  1. 二进制大小只需在基准/0014.File_io/file_io中使用基准。伙计，您应该避免作为瘟疫TBH流。它不健康。
平台视窗MingW-W64 GCC 11.0.0 msvcrt + libstdc ++ +静态编译
方法二进制大小评论
Fstream 925kb使用fstream对您的健康不利，因为std :: locale both bo bot二进制二进制。
fast_io :: obuf_file 155kb
fast_io :: c_file_unlocked 157KB我砍了MSVCRT的文件*实现
fast_io :: c_file 157KB线程安全。我砍了MSVCRT的文件*实现
fast_io :: filebuf_file 933kb我入侵了libstdc ++的std :: filebuf实现。 C ++流很烂
  1. 代码转换

生成100000000？表情符号通过基准/0020.UTF/fill_nc.cc中使用该程序

基准在示例中/0043.ICONV通用ICONV中。 （以UTF-8至GB18030为例）ICONV测试：

平台视窗MingW-W64 GCC 11.0.0 MSVCRT+ LIBSTDC ++
方法经过时间评论
ICONV命令1.529
unidence.cc 1.293使用Posix libiconv

UTF8-> UTF16LE

基准为示例/0022.UTF

ICONV测试：

平台视窗MingW-W64 GCC 11.0.0 MSVCRT+ LIBSTDC ++
方法经过时间评论
ICONV命令0.967 GNU ICONV。没有糟糕的bom
utf8_file_to_utf16_file.cc 0.498我使用UTF-UTILS项目提供的SSE算法。

UTF8-> UTF32LE

基准为示例/0022.UTF

ICONV测试：

平台视窗MingW-W64 GCC 11.0.0 MSVCRT+ LIBSTDC ++
方法经过时间评论
ICONV命令0.844 GNU ICONV。没有糟糕的bom
utf8_file_to_utf32_file.cc 0.442S我使用UTF-UTILS项目提供的SSE算法。

学分

由于各种开源项目的宝贵贡献，该项目的创建和开发成为可能。尽管该代码未直接从这些项目中复制，但我将其用作参考，并重新实现它们以适合本库的特定目的。在某些情况下，需要对原始代码进行修改。我感谢这些项目及其开发人员的承诺，使他们的代码开放并可以访问更广泛的社区。

项目URL
grisu-opact https://github.com/jk-jeon/grisu-exact
ryu https://github.com/ulfjack/ryu
SHA Intrinsics https://github.com/noloader/sha-intrinsics
SHA1 https://github.com/vog/sha1
UTF-UTILS https://github.com/bobsteagall/utf_utils
Jenkins-Hash-Java https://github.com/vkandy/jenkins-hash-java
MD5 https://github.com/jieweiwei/md5
反应https://github.com/reactos/reaectos
dirent_h https://github.com/win32ports/dirent_h
GNU C库https://www.gnu.org/software/libc/
GNU Newlib https://sourceware.org/newlib/
Dragonbox https://github.com/jk-jeon/dragonbox
Jeaiii https://github.com/jeaiii/itoa
加密++ https://github.com/weidai11/cryptopp
myitoa https://gitee.com/xjkp2283572185/mystd
展开
附加信息
相关应用
为您推荐
相关资讯 全部