类库大魔王
类库大魔王 正处于中年迷茫期的C++、Go苦手,努力活着

关于程序运行效率


  同事为了能快速地打印输出格式化的字符串,已经被弄得精疲力竭了,呵呵。这些字符串来源于Ruby解释器的输出,包括各种复杂的信息,所以需要在显示前进行相关的处理,比如提取出放在行首的颜色信息,把字符串断行等等。目前的问题是,输出显示很慢,要么就是闪烁,要么就是脚本执行已经被中断了,它还在那里慢吞吞地输出,其实确实字符串已经送到了,但进行字符串处理的过程太慢,导致脚本执行中断时,还堆积了很多没处理的字符串。
  看一下我们这个项目的代码,一般都是只求功能的实现,几乎从来不关心代码运行效率的问题。我一直也是这样的毛病,以前也没怎么想过特意去怎么优化。现在这个事情突然让我对这方面很是关注。
  一般说来,以这个例子来说,要解决,首先就是要使用更高效的算法,看到同事写的那一段代码,确实是很低效的,大量的字符串重复拷贝、对象创建和销毁、字符串匹配等等都是很耗费时间的操作,又不注意稍微节省点用,照老大的说法,一个CString被复制了几次,用个引用效率也能高一些啊!然后可以考虑从CPU层面的优化,当然当前都是调试版本处理,也许效果还不是很明显。
  我想了一下,如果是我来做那部分东西,我会怎么办。首先,我可能会把所有的CString都用C++标准库里的string/wstring来代替。其次,我应该尽量会避免每次收到一个字符串时就new一个结构体,里面还有个CString成员,这样的分配内存和创建对象操作在这种场合都太费时间了。然后是,开一个合适大小的内存池,这样一边可以追加,一边可以取出处理。再就是尽量提高匹配的效率,选择一些比较高效的算法以及好好改写程序逻辑和代码结构。最后是,RichEdit似乎也有一部分问题,可以考虑自己画,把所有接收到的内容先写入一个文件,或某块内存,每次自己处理滚动条消息,然后计算比例,画出相应的部分内容,如果用双缓冲画几行字,即使用GDI应该也还可以吧。不过这样纯粹是我的空想,基本没有实践支持,所以具体效果如何,以及复杂度如何,我也不得而知。

感觉本文不错,不妨小额鼓励我一下!
如果你有Visa、MasterCard之类的国际银行卡,也可以考虑以下选项:
如果你看不到评论框,说明Disqus被墙了。