挖井

类库大魔王的挖井日记

挖一口属于自己的井


关于程序运行效率

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

本文地址:

https://minidump.info/blog/2007/07/e5-85-b3-e4-ba-8e-e7-a8-8b-e5-ba-8f-e8-bf-90-e8-a1-8c-e6-95-88-e7-8e-87/

感觉本文不错,不妨小额鼓励我一下!
上一篇

被吞噬ing

  随便翻了下阿菲和小思宇的blog看看,想起自己的blog,都已经被工作和程序吞噬了,几乎没有生活了。不知道这是好事还是坏事。  打到我那里的问题堆积得高居榜首,结果被人说了,说这周晚上应该要加点班,于是今晚就很听话地在那里加班,改问题、写文档。难得又加班一回,就给小丫头发邮件,结果好像还被...…

Job 全文阅读
下一篇

今天去加班了

  今天去加班了,难得哦,突然一下子变得很忙,这星期连续三天晚上加班,对我来说几乎是难以想像的啊。加班回来就先给妈妈打电话,然后给阿姨发短信。  给小丫头打电话,没人接,于是放下,看网页。过了一会儿小丫头发短信来说,9点以后她就接听免费了。于是安安份份地等到9点,再给小丫头打。这次小丫头似乎心...…

lookfor 全文阅读