printf的减慢我的计划 [英] printf slows down my program

查看:133
本文介绍了printf的减慢我的计划的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个小的C程序来计算哈希值(哈希表)。在code看起来挺干净的,我希望,但有一些无关的它,是缠着我。

I have a small C program to calculate hashes (for hash tables). The code looks quite clean I hope, but there's something unrelated to it that's bugging me.

我可以很容易地产生约0.2-0.3秒,约一百万哈希值(与基准的/ usr / bin中/时间)。然而,当我的printf()在for循环inging他们,程序减慢至约5秒。

I can easily generate about one million hashes in about 0.2-0.3 seconds (benchmarked with /usr/bin/time). However, when I'm printf()inging them in the for loop, the program slows down to about 5 seconds.


  1. 这是为什么?

  2. 如何使它更快吗? mmapp()ING标准输出可能?

  3. 如何stdlibc在关于这个设计的,怎么还可能得到改善?

  4. 怎么可能内核支持的更好?它将如何需要进行修改,使当地的文件吞吐量(插座,管道等)的真快?

我期待着有趣的和详细的答复。谢谢你。

I'm looking forward for interesting and detailed replies. Thanks.

PS:这是一个编译器建设工具,所以不要害羞进入细节。虽然这无关的问题本身,我只是想指出,细节引起我的兴趣。

PS: this is for a compiler construction toolset, so don't by shy to get into details. While that has nothing to do with the problem itself, I just wanted to point out that details interest me.

附录

我在寻找解决方案和解释更程序化的方法。事实上,管道做这项工作,但我没有在什么用户做控制。

I'm looking for more programatic approaches for solutions and explanations. Indeed, piping does the job, but I don't have control over what the "user" does.

当然,我在做测试,现在,这不会是普通用户来完成。但是,这并不改变的事实,一个简单的printf()减慢的过程,这是我试图找到一个最佳的编程解决方案的问题。

Of course, I'm doing a testing right now, which wouldn't be done by "normal users". BUT that doesn't change the fact that a simple printf() slows down a process, which is the problem I'm trying to find an optimal programmatic solution for.


补遗 - 令人惊讶的结果

参考时间是普通的printf()的一个TTY内来电大约需要4分钟20秒。

The reference time is for plain printf() calls inside a TTY and takes about 4 mins 20 secs.

下一个测试的/ dev /分(例如Konsole的)的输出速度高达约5秒

Testing under a /dev/pts (e.g. Konsole) speeds up the output to about 5 seconds.

有大约相同量的时间使用setbuffer与()在我的测试code键的尺寸的16384时,几乎是相​​同的为8192:约6秒钟

It takes about the same amount of time when using setbuffer() in my testing code to a size of 16384, almost the same for 8192: about 6 seconds.

使用时setbuffer与()有显然无影响:它需要的时间是相同的(在TTY约4分钟,在PTS约5秒)

setbuffer() has apparently no effect when using it: it takes the same amount of time (on a TTY about 4 mins, on a PTS about 5 seconds).

令人震惊的事情是,如果我开始在TTY1的测试,然后的切换到另一个TTY 的,它确实需要一样的作为一个PTS:约5秒。

The astonishing thing is, if I'm starting the test on TTY1 and then switch to another TTY, it does take just the same as on a PTS: about 5 seconds.

结论:内核做了哪些具有可访问性和用户友好的事情。呵呵!

Conclusion: the kernel does something which has to do with accessibility and user friendliness. HUH!

通常情况下,它应该是同样缓慢不管你盯着TTY而它的启动,或者您切换到另一个TTY。

Normally, it should be equally slow no matter if you stare at the TTY while its active, or you switch over to another TTY.


课程:运行输出密集型程序时,切换到另一个TTY

Lesson: when running output-intensive programs, switch to another TTY!

推荐答案

无缓冲输出是很慢的。

在默认情况下标准输出是完全缓冲的,但是连接到终端时,标准输出是无缓冲或线 - 缓冲。

By default stdout is fully-buffered, however when attached to terminal, stdout is either unbuffered or line-buffered.

使用尝试在缓冲开关标准输出 setvbuf用来(),就像这样:

Try to switch on buffering for stdout using setvbuf(), like this:

char buffer[8192];

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

这篇关于printf的减慢我的计划的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆