我有一个在多用户环境中用python编写的不同工具组成的框架。在
当我第一次登录到系统并启动一个命令时,只需6秒钟就可以显示几行帮助。如果我立即再次发出相同的命令,则需要0.1s。几分钟后,它将恢复到6s(短暂缓存的证明)
系统中的文件吞吐量可能很低,因为系统的文件量应该很低。在
strace -e open python tool | wc -l
显示启动该工具时访问的2154个文件。在
^{pr2}$显示正在寻找1945份丢失的文件。(一个非常糟糕的命中率是你问我:-)
我有一种预感,加载工具所花费的过多时间是通过查询GPFS中所有这些文件来消耗的,并且这些文件被缓存以备下次调用(在系统或GPFS级别),尽管我不知道如何测试/证明它。 我对系统没有根访问权限,只能写入GPFS和/tmp。在
有没有可能改善这个python quest for missing files
?在
你知道如何用一种简单的方法来测试它吗? (在/tmp上重新安装所有东西并不简单,因为涉及到很多软件包,virtualenv也没有帮助(我想),因为它只是链接gpfs系统上的文件)。在
当然,有一种选择是让守护进程分叉,但这远不是“简单”的,而是最后的解决方案。在
谢谢你的阅读。在
使用imp模块怎么样?特别是有一个功能: imp.find_模块(模块,路径)此处http://docs.python.org/2.7/library/imp.html
至少这个例子(见下文)减少了open()系统调用的数量,而不是简单的“import numpy,scipy”:(更新:但似乎不可能通过这种方式显著减少系统调用…)
我想你最好检查一下你的PYTHONPATH是空的还是小的,因为这也会增加加载时间。在
Python2首先查找与当前包相关的模块。如果你的库代码有很多顶级模块的导入,那么这些都会首先被查找为相对的。因此,如果包
foo.bar
导入os
,那么Python首先查找foo/bar/os.py
。这个错误也由Python本身缓存。在在Python3中,默认值改为绝对导入;您可以切换到Python2.5或更高版本,以便在每个模块中使用绝对导入:
文件查找未命中的另一个来源是加载} module 创建这些缓存:
^{pr2}$.pyc
字节码缓存文件;如果这些文件由于某种原因而丢失(文件系统对于当前的Python进程不可写),那么Python将在每次运行时继续查找这些文件。可以使用^{前提是你用正确的写权限运行它。在
相关问题 更多 >
编程相关推荐