竞赛中,遇到大数据时,往往读文件成了程序运行速度的瓶颈,需要更快的读取方式。相信几乎所有的C++学习者都在cin机器缓慢的速度上栽过跟头,于是从此以后发誓不用cin读数据。还有人说Pascal的read语句的速度是C/C++中scanf比不上的,C++选手只能干着急。难道C++真的低Pascal一等吗?答案是不言而喻的。一个进阶的方法是把数据一下子读进来,然后再转化字符串,这种方法传说中很不错,但具体如何从没试过,因此今天就索性把能想到的所有的读数据的方式都测试了一边,结果是惊人的。

竞赛中读数据的情况最多的莫过于读一大堆整数了,于是我写了一个程序,生成一千万个随机数到data.txt中,一共55MB。然后我写了个程序主干计算运行时间,代码如下:

#include <ctime>
int main()
{
int start = clock();
//DO SOMETHING
printf("%.3lf\n",double(clock()-start)/CLOCKS_PER_SEC);
}

最简单的方法就算写一个循环scanf了,代码如下:

const int MAXN = 10000000;

int numbers[MAXN];

void scanf_read()
{
freopen("data.txt","r",stdin);
for (int i=0;i<MAXN;i++)
scanf("%d",&numbers[i]);
}

可是效率如何呢?在我的电脑Linux平台上测试结果为2.01秒。接下来是cin,代码如下

const int MAXN = 10000000;

int numbers[MAXN];

void cin_read()
{
freopen("data.txt","r",stdin);
for (int i=0;i<MAXN;i++)
std::cin >> numbers[i];
}

出乎我的意料,cin仅仅用了6.38秒,比我想象的要快。cin慢是有原因的,其实默认的时候,cin与stdin总是保持同步的,也就是说这两种方法可以混用,而不必担心文件指针混乱,同时cout和stdout也一样,两者混用不会输出顺序错乱。正因为这个兼容性的特性,导致cin有许多额外的开销,如何禁用这个特性呢?只需一个语句std::ios::sync_with_stdio(false);,这样就可以取消cin于stdin的同步了。程序如下:

const int MAXN = 10000000;

int numbers[MAXN];

void cin_read_nosync()
{
freopen("data.txt","r",stdin);
std::ios::sync_with_stdio(false);
for (int i=0;i<MAXN;i++)
std::cin >> numbers[i];
}

取消同步后效率究竟如何?经测试运行时间锐减到了2.05秒,与scanf效率相差无几了!有了这个以后可以放心使用cin和cout了。

但是,ios::sync_with_stdio(false)

sync的功能就是将你cin的光标与stdio的光标保持同步。一旦关掉之后就不要再用stdio了(stdio库里的东西)→_→一般而言关了sync之后快速读入scanf与cin是不能共存,有可能导致stdin/stdout缓冲区出错。

接下来让我们测试一下读入整个文件再处理的方法,首先要写一个字符串转化为数组的函数,代码如下

const int MAXS = 60*1024*1024;
char buf[MAXS]; void analyse(char *buf,int len = MAXS)
{
int i;
numbers[i=0]=0;
for (char *p=buf;*p && p-buf<len;p++)
if (*p == ' ')
numbers[++i]=0;
else
numbers[i] = numbers[i] * 10 + *p - '0';
}

把整个文件读入一个字符串最常用的方法是用fread,代码如下:

const int MAXN = 10000000;
const int MAXS = 60*1024*1024; int numbers[MAXN];
char buf[MAXS]; void fread_analyse()
{
freopen("data.txt","rb",stdin);
int len = fread(buf,1,MAXS,stdin);
buf[len] = '\0';
analyse(buf,len);
}

上述代码有着惊人的效率,经测试读取这10000000个数只用了0.29秒,效率提高了几乎10倍!掌握着种方法简直无敌了,不过,我记得fread是封装过的read,如果直接使用read,是不是更快呢?代码如下:

const int MAXN = 10000000;
const int MAXS = 60*1024*1024; int numbers[MAXN];
char buf[MAXS]; void read_analyse()
{
int fd = open("data.txt",O_RDONLY);
int len = read(fd,buf,MAXS);
buf[len] = '\0';
analyse(buf,len);
}

测试发现运行时间仍然是0.29秒,可见read不具备特殊的优势。到此已经结束了吗?不,我可以调用Linux的底层函数mmap,这个函数的功能是将文件映射到内存,是所有读文件方法都要封装的基础方法,直接使用mmap会怎样呢?代码如下:

const int MAXN = 10000000;
const int MAXS = 60*1024*1024; int numbers[MAXN];
char buf[MAXS];
void mmap_analyse()
{
int fd = open("data.txt",O_RDONLY);
int len = lseek(fd,0,SEEK_END);
char *mbuf = (char *) mmap(NULL,len,PROT_READ,MAP_PRIVATE,fd,0);
analyse(mbuf,len);
}

经测试,运行时间缩短到了0.25秒,效率继续提高了14%。到此为止我已经没有更好的方法继续提高读文件的速度了。回头测一下Pascal的速度如何?结果令人大跌眼镜,居然运行了2.16秒之多。程序如下:

const
MAXN = 10000000;
var
numbers :array[0..MAXN] of longint;
i :longint;
begin
assign(input,'data.txt');
reset(input);
for i:=0 to MAXN do
read(numbers[i]);
end.

为确保准确性,我又换到Windows平台上测试了一下。结果如下表:

方法/平台/时间(秒) Linux gcc Windows mingw Windows VC2008
scanf 2.010 3.704 3.425
cin 6.380 64.003 19.208
cin取消同步 2.050 6.004 19.616
fread 0.290 0.241 0.304
read 0.290 0.398 不支持
mmap 0.250 不支持 不支持
Pascal read 2.160 4.668  

从上面可以看出几个问题

  1. Linux平台上运行程序普遍比Windows上快。
  2. Windows下VC编译的程序一般运行比MINGW(MINimal Gcc for Windows)快。
  3. VC对cin取消同步与否不敏感,前后效率相同。反过来MINGW则非常敏感,前后效率相差8倍。
  4. read本是linux系统函数,MINGW可能采用了某种模拟方式,read比fread更慢。
  5. Pascal程序运行速度实在令人不敢恭维。

C++最快的读取文件的方案(scanf,cin(及取消sync),fread)的详细对比的更多相关文章

  1. 探寻C++最快的读取文件的方案 ——C++ IO优化

    在竞赛中,遇到大数据时,往往读文件成了程序运行速度的瓶颈,需要更快的读取方式.相信几乎所有的C++学习者都在cin机器缓慢的速度上栽过跟头,于是从此以后发誓不用cin读数据.还有人说Pascal的re ...

  2. 【转载】探寻C++最快的读取文件的方案

    原文地址:https://www.byvoid.com/blog/fast-readfile/ 在竞赛中,遇到大数据时,往往读文件成了程序运行速度的瓶颈,需要更快的读取方式.相信几乎所有的C++学习者 ...

  3. 探寻C++最快的读取文件的方案

    https://www.byvoid.com/blog/fast-readfile/ 在竞赛中,遇到大数据时,往往读文件成了程序运行速度的瓶颈,需要更快的读取方式.相信几乎所有的C++学习者都在cin ...

  4. [Repost] 探寻C++最快的读取文件的方案

    作者:BYVoid(https://www.byvoid.com/zhs/blog/fast-readfile) 版权协议:CC BY-NC-SA 3.0 Unported 在竞赛中,遇到大数据时,往 ...

  5. python3读取文件指定行的三种方案

    技术背景 考虑到深度学习领域中的数据规模一般都比较大,尤其是训练集,这个限制条件对应到实际编程中就意味着,我们很有可能无法将整个数据文件的内容全部都加载到内存中.那么就需要一些特殊的处理方式,比如:创 ...

  6. 快学Scala 第十五课 (二进制读取文件,写文件,访问目录,序列化)

    二进制读取文件: val file = new File("F:\\scalaWorkspace\\ScalaLearning\\files\\test.txt") val in ...

  7. 大文件拆分方案的java实践(附源码)

    引子 大文件拆分问题涉及到io处理.并发编程.生产者/消费者模式的理解,是一个很好的综合应用场景,为此,花点时间做一些实践,对相关的知识做一次梳理和集成,总结一些共性的处理方案和思路,以供后续工作中借 ...

  8. MongoDb gridfs-ngnix文件存储方案

          在各类系统应用服务端开发中,我们经常会遇到文件存储的问题. 常见的磁盘文件系统,DBMS传统文件流存储.今天我们看一下基于NoSQL数据库MongoDb的存储方案.笔者环境 以CentOS ...

  9. java 读取文件——按照行取出(使用BufferedReader和一次将数据保存到内存两种实现方式)

    1.实现目标 读取文件,将文件中的数据一行行的取出. 2.代码实现 1).方式1: 通过BufferedReader的readLine()方法. /** * 功能:Java读取txt文件的内容 步骤: ...

随机推荐

  1. .NET面试题系列(七)IIS

    应用程序池的集成模式和经典模式的区别 应用程序池模式会影响服务器处理托管代码请求的方式. 如果托管应用程序在采用集成模式的应用程序池中运行,服务器将使用 IIS 和 ASP.NET 的集成请求处理管道 ...

  2. js截取图片上传(仅原理)----闲的无聊了代码就不共享了!写的难看,不好意思给你们看了(囧)

    就算世界再坑爹,总有一些属性能带你走出绝望(伟大的absolute) 今天吐槽一下!......在我的世界里没有正统UI,所以效果图永远都是那么坑爹! 这里我要感谢有个position:absolut ...

  3. javascript实现的拖拽回放

    这个功能很简单,直接贴代码啊: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "ht ...

  4. Linux学习6-套接字

    套接字 1.什么是套接字? 套接字(socket)是一种通信机制,凭借这种机制,客户/服务器系统的开发工作既可以在本地单机上进行,也可以跨网络进行. 2.套接字应用程序是如何通过套接字来维持一个连接的 ...

  5. 20155230 2016-2017-2 《Java程序设计》第九周学习总结

    20155230 2016-2017-2 <Java程序设计>第九周学习总结 教材学习内容总结 第十六章 statement在不使用时所关联的resultset也会自动关闭. 要让SQL执 ...

  6. Android启动过程

    1.背景知识                                                          Init进程是Linux环境下非常重要的一个进程,而Zygote进程是J ...

  7. 解决C/C++语言中全局变量重复定义的问题

    前言 今天,在整理自己的代码的时候,考虑到我写的代码从一至终都是在一个cpp文件里面.于是,想把自己的代码中的各个模块分离开来,以便更好地阅读和管理. 遇到的问题 我的做法是: 宏定义.结构体定义.函 ...

  8. android上使用蓝牙设备进行语音输入

    主要实现步骤如下:1.确保已经和蓝牙耳机配对连接上.2.开启蓝牙信道AudioManager mAudioManager = (AudioManager)getSystemService(Contex ...

  9. CSS之:active选择器

    Active的一段话 active的英文解释为“积极的”,表现在鼠标上就是点击的意思.关于active选择器最多的示例恐怕就是应用在链接上面的,然而打开链接是一个一瞬间的动作,这不能很好的体现acti ...

  10. Linux系统运维笔记(二),Linux文件编辑命令

    Linux系统运维笔记 Linux文件编辑命令 首先我们使用命令 vi filename 打开一个文件,这个时候进入到的是命令模式 接下来我们按i,然后键盘随便输入写内容. 然后按ESC重新进入到命令 ...