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