Knuth说过盲目的优化是罪恶的根源,这话一点不假,因为经理说“你这个动态返回太慢,要改进。” 于是开始了这两天
的优化历程。
东西很简单,将一个地区分块,按照octree,使用16格分块,总共5层。建立索引。每次导入的线条都预生成
索引。 所以我要一个索引器。
这个索引器没什么特别,普通的递归而已。 到最后开始存放索引的时候,问题出现了,:这个东西有些大,变成
文件有276m之大。在每次网络传输都占用了大量的时间。我的索引数据一开始存放在tokyo cabinet上。(因为
以前的测试结果还令人满意)。 可惜这么多的数据序列化和传输占用了大量时间,还是慢。于是想到了并行。
用executor将一些关键的任务分解,嗯,,似乎快了。快了至少有两倍。好像也达到目标了。
今天下午想想,有些不爽,想起以前曾经用过的db4o.于是拿出来试一下,不用并行,结果大跌眼镜:居然比优化过的方案
还快两倍。 仔细想想发现之前的优化极其无聊:这个索引基本上每个tenant只需要一个,用不着每次都从server拉下来。
再优化,网络的瓶颈还是摆在那里的。
不过并行计算还是有用的,中间有一步过滤使用executor在我的 dual core 2.5g上快了大约两倍。如果cores数量
上去,还可以更快。 我还考虑以后用scala的actor来代替现在的 executor方式重新实现一个。