dpi*_*h40 27 python io performance multithreading
我用Python编写了一个工作程序,基本上解析了一批二进制文件,将数据提取到数据结构中.每个文件大约需要一秒钟来解析,这意味着数千个文件的小时数.我已经成功实现了具有可调整线程数的批处理解析方法的线程版本.我在具有不同线程数的100个文件上测试了该方法,每次运行计时.以下是结果(0个线程指的是我原来的预线程代码,1个线程到新版本运行,产生一个线程).
0 threads: 83.842 seconds
1 threads: 78.777 seconds
2 threads: 105.032 seconds
3 threads: 109.965 seconds
4 threads: 108.956 seconds
5 threads: 109.646 seconds
6 threads: 109.520 seconds
7 threads: 110.457 seconds
8 threads: 111.658 seconds
Run Code Online (Sandbox Code Playgroud)
虽然生成一个线程比使主线程完成所有工作所带来的性能提升很小,但增加线程数实际上会降低性能.我本来希望看到性能提升,至少最多四个线程(每个机器核心一个).我知道线程有相关的开销,但我不认为这对于一位数的线程来说太重要了.
我听说过"全局解释器锁定",但是当我最多移动到四个线程时,我确实看到了相应的内核数量 - 两个线程两个核心在解析期间显示活动,依此类推.
我还测试了一些不同版本的解析代码,看看我的程序是否是IO绑定的.它似乎不是; 只读文件需要相对较小的时间; 处理文件几乎就是全部.如果我不执行IO并处理已经读取的文件版本,我添加第二个线程会损害性能,第三个线程会略微改进它.我只是想知道为什么我不能利用我的计算机的多核来加快速度.请发布我可以澄清的任何问题或方法.
NPE*_*NPE 39
令人遗憾的是,CPython中的情况如何,主要是由于Global Interpreter Lock(GIL).CPU绑定的Python代码不能跨线程扩展(另一方面,I/O绑定代码可能会在某种程度上扩展).
David Beazley提供了一个内容丰富的演讲,他讨论了围绕GIL的一些问题.视频可以在这里找到(感谢@Ikke!)
我的建议是使用multiprocessing
模块而不是多个线程.
归档时间: |
|
查看次数: |
18154 次 |
最近记录: |