@Zzzzzzzzz @yeyuexia 我早看到了啊，这些都没什么用，多核计算并不能提高这块的计算速度来到多大的性能提升， cmath 和 math 比较好像并没有多大个区别

@yeyuexia numpy log 和 math 比较还没 math 快, 进程线程协程都没有什么用，用了反倒会变慢，毕竟不是 IO 密集型操作

这个世界还是需要一个共享的精神， linux 是完全免费的， mysql 是完全免费， java 也是免费的等等世界顶尖的产品都是免费！自由开放不应该被恶意揣测，我公开一个我自己的 http://blog.xenvoy.org/

@calease 我肯定测试过的啊，
@yepinf 用 c++也不一定比我快啊

@vm 与产品经理斗其乐无穷；与测试斗其乐无穷；然后可以安心写代码

@ShiHou 感谢你的热心帮助，我测试了才知道主要速度卡在统计词频上面，跟多线程啥都没关系。后来想起来 python 本身就自带词频统计模块, collections,发现在最近记忆力下降了
代码就变成了
counter = [i for i in xrange(100000)]
# 得到某一个词的词频就是
counter[words] # 变成了查 hash 了
实际测试速度：处理 30 万词，消耗 6 秒

@ShiHou 这种运算下面多线程和 coroutine 并不能带来速度多少的优势

@ShiHou 差不多就这个意思，数据量大了后就开始特别慢了，也就是 20 多万而已

设置好主键把内存池和线程打高一点设置好索引，其余交给数据库吧

看毛泽东思想，看完之后你就可以大大提升了

没 USB 插口一律差评

@yumijie 很多都是你自己留下的

@murmur 我说的是基本，代表很多，而不是全部，你非要找出例外出来，我只能告诉你里面还有事基于其中还有很大一部分是基于 scrapy 开发的，你可以继续找例外出来

@cdwyd mmap 读取文件，然后用 set 去重， mmap 申请的不是 buff 而是内存分页，只要你是 64 位系统就能突破限制

除了没搞过 LUA 扩展和嵌入式，其它都玩过

这个水太 low 了，最少也要 VOSS

费这个力气干嘛，有更简单解决访问方案啊！
with open('ufiles.txt', 'r') as f:
with contextlib.closing(mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)as m:
with open(‘ object.txt ’, 'wb') as new_file:
new_file.wirtelines(list(set(list)))

swift 是雨燕怎么是雷鸟啊！
python 从入门到饲养