|
精华帖 (0) :: 良好帖 (1) :: 新手帖 (1) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-08-26
最后修改：2009-08-26
yysolo 写道 从优化的角度:
1. 开一个大的buffer, 然后用fread 2. 多线程，一个读，多个处理。降低IO的时间。如果是目录，必须多线程 3. 在算法中降低分配内存的次数，使用1中的buffer,基本做到zero-copy 4. GCC -O2 5. 换文件格式，换文件系统 .... 表层的优化完成后，通过工具找热点 看了下算法并不耗时，LZ多了解一下C，以LZ的机器，单线程60M/s还是有可能的。 1，2，3弄好了，提高IO的效率，考虑换块磁盘或者换架构。最后再考虑5 LZ可以下一个Beyond compare体会专业级的diff工具的性能 前期加载文件那部分不在计算耗时的范围内，仅计算search函数内的耗时。所以你说的这些好像都用不上，不过还是谢谢你的回复 PS:Beyond compare体验过了，它是单个文件进行比较，虽然有文件夹比较，但文件夹比较只是表面（修改日期，创建日期，长度）比较，并不比较文件内容，然后当你确实要比较内容时还要进行一次点击 |
| 返回顶楼 | |
|
发表时间：2009-08-31
这个要MARK一下，最近在做海量数据报文解析~~用python的确有性能不足~
|
| 返回顶楼 | |
|
发表时间：2009-08-31
diff3不是有個專門算法的么，我記得還看過論文。不知是否可以給樓主參考。
|
| 返回顶楼 | |
|
发表时间：2009-08-31
Magicloud 写道 diff3不是有個專門算法的么，我記得還看過論文。不知是否可以給樓主參考。
不用了，我想过了，用diff的算法怎么也不比不上分词索引。不过能提供文档的话还是谢谢 |
| 返回顶楼 | |
|
发表时间：2009-08-31
能不能麻烦楼主把你程序的应用场景交代一下?上来就贴代码,云里雾里
|
| 返回顶楼 | |
|
发表时间：2009-09-01
|
| 返回顶楼 | |
|
发表时间：2009-09-07
看了楼主的博客，你的这种方法不可行，太暴力，最基本的I/O瓶颈就突破不了
给你算笔账，假设你服器上有6块硬盘做raid0，吞吐量按400M/s算，你的文档库有20G文档（已经够少了吧），那么检索一遍的时间是50s，你认为用户会有50s的耐心等待检索结果吗，而且代价是服务器满I/O负载 如果要是1000个用户并发检索呢？哦，的确可以将检索词排队，下次检索一次取出，但每次检索的时间都是50s，这就说明最差情况下用户的等待时间是100s 可以将检索分布式，但代价是为了保证用户能在1s内检索到数据，数据需要分布到50台机器上，20G数据分配到50台机器上，你自己想一下吧 |
| 返回顶楼 | |
|
发表时间：2009-09-07
zhwang 写道 看了楼主的博客，你的这种方法不可行，太暴力，最基本的I/O瓶颈就突破不了
给你算笔账，假设你服器上有6块硬盘做raid0，吞吐量按400M/s算，你的文档库有20G文档（已经够少了吧），那么检索一遍的时间是50s，你认为用户会有50s的耐心等待检索结果吗，而且代价是服务器满I/O负载 如果要是1000个用户并发检索呢？哦，的确可以将检索词排队，下次检索一次取出，但每次检索的时间都是50s，这就说明最差情况下用户的等待时间是100s 可以将检索分布式，但代价是为了保证用户能在1s内检索到数据，数据需要分布到50台机器上，20G数据分配到50台机器上，你自己想一下吧 呵呵，是有点很暴力的感觉，只是我想说，这里面没有I/O的事。所有的操作都是在内存中完成。 PS：我已经放弃这种算法了。确实不可行。 |
| 返回顶楼 | |
|
发表时间：2009-09-19
谢谢楼主的这篇帖子,学到了好多.
|
| 返回顶楼 | |
|
发表时间：2010-03-07
为什么不用perl，这是perl的强项
|
| 返回顶楼 | |
