如果我们知道所有文件都将被加载到内存中并且我们可以负担得起,
在 python变量中加载整个文件(可能是二进制文件)有什么缺点(如果有的话)或限制(如果有的话).如果这在技术上是可行的,应该避免这种情况,为什么？
关于文件大小问题,应该限制此解决方案的最大大小？为什么？
实际的加载代码可以是 this stackoverflow entry 中提出的代码.
示例代码是：
def file_get_contents(filename):
with open(filename) as f:
return f.read()
content = file_get_contents('/bin/kill')
... code manipulating 'content' ...
[编辑]
想到的代码操作(但可能不适用)是标准列表/字符串运算符(方括号,’符号)或一些字符串运算符(‘len’,’in’运算符,’count’,’endswith’/’ startwith’,’split’,’translation’…).
虽然你得到了很好的回答,但似乎没有人回答你问题的这一部分(正如你在问题中提出许多问题时经常发生的那样; – )……：
Regarding file size concerns, to what maximum size this solution should be limited ?. And why ?
最重要的是,这个特定的Python进程实际使用了多少物理RAM(所谓的“工作集”),而不会过度惩罚整个系统性能的其他方面.如果你的“工作集”超过了物理RAM,你将进行分页并交换到磁盘,你的性能会迅速下降(直到所谓的“颠簸”状态基本上所有可用的周期都会进入获取页面进出的任务,实际工作量可以忽略不计.
除此之外,一个相当适度的数量(一般来说最多几MB)可能会被可执行代码(Python自己的可执行文件,DLL或.so)以及主动的字节码和一般支持数据结构所占用.在记忆中需要;在一台没有做其他重要或紧急任务的典型现代机器上,与整体可用的千兆字节RAM相比,您几乎可以忽略这一开销(尽管嵌入式系统的情况可能不同等).
其余的都可用于您的数据 – 包括您正在读入内存的此文件,以及任何其他重要的数据结构.文件数据的“修改”通常可以(暂时)占用文件内容大小的两倍(如果您将其保存在字符串中) – 当然,如果您保留一份副本旧数据以及制作新的修改副本/版本.
因此,对于典型的现代32位机器上的“只读”使用,例如总体上2GB的RAM,读入内存(比方说)1.5 GB应该没问题;但如果你正在进行“修改”,那么它必须大大小于1 GB(如果你在内存中有其他重要的数据结构,那就更少了！).当然,在具有64位构建的Python,64位操作系统和16 GB RAM的专用服务器上,实际限制在非常不同之前 – 大致与实际上可用RAM的大不相同的比例.
例如,King James的圣经文本可下载 here (解压缩)大约4.4 MB;因此,在具有2 GB RAM的计算机中,您可以在内存中保留大约400个略微修改过的副本(如果没有其他请求内存),但是,在具有16(可用且可寻址)GB的RAM的计算机中,您可以保持超过3000份这样的副本.
进群“960410445” 即可获取数十套PDF！