日期:2014-05-17  浏览次数:21099 次

由前帖引发:代码可读性与性能的选择
前一帖子参考:for的效率测试和结果,分享一下
里面很多同学都说,我提的那点性能,影响不大,不建议改进,而建议使用可读性好的代码写法,这里我分享一个我的实际经验。

我现在负责一个日pv访问过千万的搜索接口,数据大约几十万条
因为SqlServer的LIKE效率太低,而SqlServer的全文检索又不尽人意,于是方案定为把这些记录全部加载到内存,代码一开始如下:
Dictionary<string, int> name_id = 加载几十万条 标题_id 的记录;
string key = "要搜索的关键词";
StringBuilder sb = new StringBuilder(10000);
foreach (KeyValuePair<string, int> pair in name_id)
{
  if (pair.Key.IndexOf(key) >= 0)
  sb.AppendFormat("{0},", pair.Value);
}
return sb.ToString()

这段代码上线后,执行效率不是很好,后来通过性能工具测试,发现问题比较大的一个地方,就是
IndexOf(key)和AppendFormat("{0},", pair.Value)占用了大约30%的执行时间
因为访问量大,加上每次访问都要循环执行IndexOf(key)几十万次
后面改成了:
foreach (KeyValuePair<string, int> pair in name_id)
{
  if (pair.Key.IndexOf(key, StringComparison.Ordinal) >= 0)
  sb.AppendFormat("{0},", pair.Value.ToString());
}

由这个例子,虽然每次的IndexOf(key)或AppendFormat("{0},", pair.Value),影响的效率可能是微秒计,但是如果执行次数多了,效率也是很可观的,比如上述例子就占了1/3的执行时间

想起了一句话:勿以善而不为。不要以为性能改善极其微小,就按自己的想法去做

------解决方案--------------------
你还来啊

------解决方案--------------------
真那么在乎性能的话就该直接用哈希表,或者专门写个key的搜索算法。
------解决方案--------------------
pair.Key.IndexOf(key) 看看这个是怎么实现的,是否能够手写优化

------解决方案--------------------
俺写的代码可读性与性能都很好。

------解决方案--------------------
我认为举得例子非常不好。这个应用需求其实应该使用搜索引擎实现,而不是这样的笨办法。
这种情况下,你无论怎么调优,怎么优化代码,搞各种技巧,能够加百分之几就非常不错了,而付出的代价则很大。不容易维护、BUG、开发调试周期长、人员变动没人敢维护等等。还不如干脆加钱买新服务器呢。
但是如果使用了合理的解决方案、效率更高的算法,则可以一下子提高几十几百倍的效率。
------解决方案--------------------
细节是需要关注的,for循环的写法大多数写的不规范,不过影响不大是因为数据量少,js里面就有个习惯要把长度给预存起来。
搜索引擎的查找原理也是索引起来,具体情况不知道呵呵
------解决方案--------------------
支持············
------解决方案--------------------
探讨

这种设计,要是被sp1234看到
肯定又是一顿喷

------解决方案--------------------
探讨

恩,通过IL查看明白了,还是基础知识不牢固

C# code
int i = 123;
Console.WriteLine((object)i.ToString());



Assembly code
.method private hidebysig static void Main(string[] args) cil managed
{
.e……

------解决方案--------------------
性能的问题根本就不是问题。可读性的问题,才是大问题。
------解决方案--------------------
。。。http://community.csdn.net/help/GetUsablePoint.htm
------解决方案--------------------
代码应该先保证可读性。
关于性能,只有通过测试,某段确实有性能问题,才会牺牲可读性换取性能。
不要一开始就纠结于性能。
------解决方案--------------------
不要函数调用 所有东西写在一起,性能最好
------解决方案--------------------
探讨
这种设计,要是被sp1234看到
肯定又是一顿喷

------解决方案--------------------
忍不住给楼主提个方案

思路:通过建立单词索引,缩小搜索范围
算法:
S1.对标题分词,建立 关键词 到 标题集合 的映射(剔除那些集合过大的单词)
S2.对用户输入分词W[1..n]
S3.找出词频最小的词 Wmin ,(词频:关键词对应的集合大小)
S3.1 在映射中找出 Wmin 对应的标题集合,调用楼主原有算法
return
S3.2. 所有的词都不出现在关键词中