printf减慢了我的程序

无缓冲输出非常慢。

默认情况下 stdout 是完全缓冲的,但是当连接到终端时, 标准输出 未缓冲或线路缓冲。

尝试打开缓冲 标准输出 使用 setvbuf() ,像这样:

char buffer[8192];

setvbuf(stdout, buffer, _IOFBF, sizeof(buffer));

您可以将字符串存储在缓冲区中,并在缓冲区满后定期将其输出到文件(或控制台)中。

如果输出到控制台,滚动通常是一个杀手。

如果您要打印到控制台,通常会非常慢。我不知道为什么,但我相信在控制台以图形方式显示输出的字符串之前,它不会返回。此外,不能将mmap()转换为stdout。

写入文件的速度应该快得多(但仍然比计算哈希慢几个数量级,所有I/O都慢)。

您可以尝试将shell中的输出从控制台重定向到文件。使用它,可以在几秒钟内创建大小为千兆字节的日志。

1. I/O总是比 直接计算。该系统具有 等待更多组件 可供使用。它 然后必须等待回应 才能继续下去。相反地 如果只是简单的计算,那么 只在 RAM和CPU寄存器。

2. 我没有测试过这个,但是将散列附加到字符串上,然后在末尾打印字符串可能会更快。虽然如果你使用C,而不是C++,这可能是一种痛苦!

恐怕3和4比我强。

由于I/O总是比CPU计算慢得多,所以您可能首先将所有值存储在最快的I/O中。因此,如果您有足够的内存,请使用RAM;如果没有,请使用文件,但它比RAM慢得多。

现在可以在以后或由另一个线程并行打印这些值。因此,计算线程可能不需要等待printf返回。

我很久以前发现的 using this technique 应该是显而易见的。 不仅I/O速度慢,特别是控制台,而且格式化十进制数字也不快。如果你能把二进制的数字放入大的缓冲区,并把它们写到一个文件中,你会发现它要快得多。

另外,谁来读呢?如果没有人需要阅读全部内容,那么就没有必要以人类可读的格式打印全部内容。

1. 为什么不按需创建字符串而不是在构建点创建字符串呢?在一秒钟内输出40屏数据是没有意义的,你怎么可能读取它呢?为什么不根据需要创建输出,只显示最后一个屏幕,然后根据需要用户滚动????

2. 为什么不使用sprintf打印到一个字符串,然后在内存中构建一个包含所有结果的连接字符串,并在最后打印?

3. 通过切换到sprintf,您可以清楚地看到格式转换花费了多少时间,以及向控制台显示结果花费了多少时间,并适当地更改代码。

4. 根据定义,控制台输出很慢,创建散列只需要操作几个字节的内存。控制台输出需要经过操作系统的许多层,这些层将具有处理线程/进程锁定等的代码。一旦它最终到达显示驱动程序,可能是9600波特设备!或者大的位图显示,像滚动屏幕这样的简单功能可能涉及操作兆字节的内存。

我猜终端类型正在使用一些缓冲输出操作,所以当您执行printf时,它不会在split微秒内输出,而是存储在终端子系统的缓冲内存中。

这可能会受到其他可能导致速度减慢的事情的影响,可能除了您的程序之外,还有一个内存密集型的操作正在运行。简而言之,可能同时发生的事情太多了,分页、交换、另一个进程的大量I/O、使用的内存配置、可能的内存升级等等。

最好将字符串连接到达到某个限制,然后在达到该限制时立即将其全部写出。或者甚至使用pthreads来执行所需的进程执行。

编辑: 至于2,3,我无法理解。4, 我对太阳不熟悉,但我知道,也曾弄乱了Solaris, 可能存在使用虚拟tty的内核选项。我承认,自从处理内核配置并重新编译它以来已经有一段时间了。因此,我的记忆可能不太好,有一个根周围的选项看。

user@host:/usr/src/linux $ make; make menuconfig **OR kconfig if from X**

这将启动内核菜单,在“设备”子树下的“视频设置”部分中进行挖掘。

编辑: 但是,通过在proc文件系统中添加一个文件(如果确实存在这样的文件),或者可能是传递给内核的一个开关(这是富有想象力的,并不意味着它确实存在),可以对内核进行一些调整,fastio

希望这有帮助, 最好的问候, 汤姆。