类库大魔王
类库大魔王 多年C++、Go项目经验,长期从事跨平台(Windows/macOS/iOS/Android)应用架构设计与开发。

关于程序运行效率后续


  话说同事那任务把他整得精疲力竭,昨天加班又是继续攻关这个遗留问题。老大的看法是RichEdit在显示的时候占用太多时间是主要原因,于是同事把RichEdit换成用Scintilla控件来进行显示,结果效率并不比RichEdit好,估计因为Scintilla是一个通用的文本编辑器,为了进行着色、词法分析等任务,在这种特殊场合下,并不是最优的方案。还是换回RichEdit,只好从提高字符串操作效率着手。把其中一部分操作原本使用CString的,全部改换成用C运行时库重写了一遍,尽量减少字符串复制操作,用原始的指针,同时也避免了原本非常频繁的CString对象的创建和销毁,再加上一点点从CPU优化的角度的编码技巧。最后发现似乎效果还是挺明显的,不过RichEdit内的数据如果一多,显示速度也会降下来,这个问题照我的看法,如果坚持要使用RichEdit的话,只能开个定时器,每一个固定的时间周期,把RichEdit中的数据减少一点,保证RichEdit中最多只存储一定数量,该数量应该还不至于明显影响显示速度的内容,否则就完全摒弃使用RichEdit,采用自己画的方案,因为每次只是画出显示的那一部分内容,速度应该很快,而难点是,要把所有内容缓冲到文件中,如何能在文件不断增长的情况下,快速准确地定位到需要进行显示的那部分内容。
  这个事件,让我对现成库的效率都产生了怀疑的心理,MFC库的慢是为众人诟病的,但不知我更习惯使用的STL效率如果,它的string类,它的各种算法不知道应用到这种场合会是什么样的效果。必要的时候还是得靠自己手动解决,看了《软件优化技术》中的一点内容,编译器优化会帮我们做不少事情,但很多时候还得程序员帮助编译器创建更优化的条件和机会。

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