英文大小写引起的性能问题
2006-09-16 13:27
218 查看
英文大小写引起的性能问题
最近在做的一个项目中要实现字母大小写无关比较,很自然的使用标准c库中的函数
tolower(),但是由于使用次数很多,对输入的字符数组每个都要使用一次,经过性能测
试,发现使用tolower函数的性能只有不使用该函数的的三分之一。
察看了一下tolower函数的源码,发现其对MT有加锁互斥操作,而做的项目正后生成
的是MT库,因此性能上会有问题。因此参考tolower函数,写了一个宏,定义如下:
#define MYTOLOWER(c) (c>='A'&&c<='Z' ? c+32:c)
用该宏来代替tolower函数,测试后发现果然使性能提高了,但还是只有不使用该函数的
的二分之一,性能还是跟原来的相差较多。
看来主要还是使用宏或函数带来的比较操作太多,导致了性能下降,那是否有方法来
减少这些比较操作呢?
后来跟人一起讨论及查了些资料,发现自己一来是就先入为主的观念,使用标准c库
函数,后面的改进仍然没有跳离函数的范畴。为何要使用函数呢,ASCII码不过256个字符,
用一表格不就可以了吗?只需一次查表操作即可。
使用一个静态表NoCaseTable[256]。赋初始值NoCaseTable[i]=tolower(i)。然后以
后原先使用tolower(c)的地方用NoCaseTable[c]来代替,显然只需要增加一次地址转移即
可,因此性能应该跟原先不使用查不多,最后试验也证明了这一点。
最近在做的一个项目中要实现字母大小写无关比较,很自然的使用标准c库中的函数
tolower(),但是由于使用次数很多,对输入的字符数组每个都要使用一次,经过性能测
试,发现使用tolower函数的性能只有不使用该函数的的三分之一。
察看了一下tolower函数的源码,发现其对MT有加锁互斥操作,而做的项目正后生成
的是MT库,因此性能上会有问题。因此参考tolower函数,写了一个宏,定义如下:
#define MYTOLOWER(c) (c>='A'&&c<='Z' ? c+32:c)
用该宏来代替tolower函数,测试后发现果然使性能提高了,但还是只有不使用该函数的
的二分之一,性能还是跟原来的相差较多。
看来主要还是使用宏或函数带来的比较操作太多,导致了性能下降,那是否有方法来
减少这些比较操作呢?
后来跟人一起讨论及查了些资料,发现自己一来是就先入为主的观念,使用标准c库
函数,后面的改进仍然没有跳离函数的范畴。为何要使用函数呢,ASCII码不过256个字符,
用一表格不就可以了吗?只需一次查表操作即可。
使用一个静态表NoCaseTable[256]。赋初始值NoCaseTable[i]=tolower(i)。然后以
后原先使用tolower(c)的地方用NoCaseTable[c]来代替,显然只需要增加一次地址转移即
可,因此性能应该跟原先不使用查不多,最后试验也证明了这一点。
相关文章推荐
- SQL嵌套查询引起的性能问题分析
- 一个由Response.Redirect 引起的性能问题的分析
- 引起数据库性能问题的因素
- Android 开发关于Button或TextView控件英文字符全部显示大小写问题
- Race Condition引起的性能问题
- iOS一个简单的设置圆角不引起性能问题的分类
- 数组初始化引起的性能问题
- 小心SQL SERVER 2014新特性——基数评估引起一些性能问题
- IE中的标记有可能引起性能问题
- 自动装箱拆箱在Java集合类框架引起的性能问题
- 表索引字段嵌套函数引起的性能问题
- 性能测试中SQL引起的性能问题
- Oracle优化01-引起数据库性能问题的因素
- Android Button 英文大小写问题
- Oracle 静态SQL引起性能问题
- 性能测试问题解决——消息头缺失引起的400错误
- Hibernate分页可能引起的性能问题
- 一个大小写引起的SVN无法Commit的问题
- oracle 回收站(recyclebin)引起的性能问题
- 一个大小写引起的SVN无法Commit的问题