Question

注意

不是是this的副本。我对找出内存消耗或问题不感兴趣，因为我已经在下面进行了。问题是为什么这样的内存消耗。

此外，即使我确实需要一种配置内存的方法，也要注意guppy（上述链接中建议的Python内存配置文件不支持Python 3，而备用guppy3不会给出准确的结果，无论结果如何，例如（请参见下面的实际尺寸）：

Partition of a set of 45968 objects. Total size = 5579934 bytes.
 Index  Count   %     Size   % Cumulative  % Kind (class / dict of class)
     0  13378  29  1225991  22   1225991  22 str
     1  11483  25   843360  15   2069351  37 tuple
     2   2974   6   429896   8   2499247  45 types.CodeType

背景

对，所以我有一个简单的脚本，可以通过两种不同的方式读取文件来进行 RAM 消耗测试：

一次读取一行文件，进行处理并丢弃（通过generators），这非常有效，建议在基本上任何大小的文件（尤其是大文件）上使用，按预期。
将整个文件读入内存（我不建议这样做，但这只是出于教育目的）。

测试脚本

import os
import psutil
import time


with open('errors.log') as file_handle:
    statistics = os.stat('errors.log')  # See below for contents of this file
    file_size = statistics.st_size / 1024 ** 2

    process = psutil.Process(os.getpid())

    ram_usage_before = process.memory_info().rss / 1024 ** 2
    print(f'File size: {file_size} MB')
    print(F'RAM usage before opening the file: {ram_usage_before} MB')

    file_handle.read()  # loading whole file in memory

    ram_usage_after = process.memory_info().rss / 1024 ** 2
    print(F'Expected RAM usage after loading the file: {file_size + ram_usage_before} MB')
    print(F'Actual RAM usage after loading the file: {ram_usage_after} MB')

    # time.sleep(30)

输出

File size: 111.75 MB
RAM usage before opening the file: 8.67578125 MB
Expected RAM usage after loading the file: 120.42578125 MB
Actual RAM usage after loading the file: 343.2109375 MB

我还添加了30秒的睡眠时间，以在操作系统级别使用awk进行检查，在其中使用了以下命令：

ps aux | awk '{print $6/1024 " MB\t\t" $11}' | sort -n

产生：

...
343.176 MB      python  # my script
619.883 MB      /Applications/PyCharm.app/Contents/MacOS/pycharm
2277.09 MB      com.docker.hyperkit

该文件包含以下行的800K个副本：

[2019-09-22 16:50:17,236] ERROR in views, line 62: 404 Not Found: The
following URL: http://localhost:5000/favicon.ico was not found on the
server.

是因为块大小还是动态分配，从而将内容按块加载，而实际上该内存中的很多未被使用？

Answer 1

在Python中打开文件时，默认情况下会以文本模式打开它。这意味着二进制数据将根据操作系统默认值或显式给定的编解码器进行解码。

与所有数据一样，文本数据由计算机中的字节表示。大多数英文字母都可以用单个字节表示，例如字母“ A”通常会翻译为数字65，或以二进制形式01000001来翻译。这种编码（ASCII）在许多情况下都足够好，但是当您想用罗马尼亚语等语言编写文本时，这已经不够用了，因为字符ă，ţ等不是其中的一部分ASCII码。

一段时间以来，人们对每种语言（组）使用了不同的编码，例如基于拉丁字母的语言的Latin-x编码组（ISO-8859-x），以及其他（尤其是CJK）种语言的其他编码。

如果要表示某些亚洲语言或几种不同的语言，则需要将一个字符编码为多个字节的编码。可以是固定数字（例如，在UTF-32和UTF-16中），也可以是可变数字，例如当今最常见的“通用”编码UTF-8。

返回Python：Python字符串接口具有许多属性，其中包括O（1）复杂度的随机访问，这意味着即使从很长的字符串中也可以非常快速地获得第1245个字符。这与紧凑的UTF-8编码冲突：因为一个“字符”（实际上是一个unicode代码点）有时长一个字节，有时长几个字节，所以Python不能仅仅跳转到内存地址start_of_string + length_of_one_character * offset，因为{ {1}}在UTF-8中有所不同。因此，Python需要使用固定字节长的编码。

出于优化原因，它并不总是使用UCS-4（〜UTF-32），因为当仅使用ASCII文本时，这会浪费很多空间。相反，Python动态选择Latin-1，UCS-2或UCS-4来在内部存储字符串。

通过示例将所有内容整合在一起

假设您要从编码为UTF-8的文件中将字符串“soluţie”存储在内存中。由于字母length_of_one_character需要表示两个字节，因此Python选择了UCS-2：

ţ

如您所见，UTF-8（磁盘上的文件）需要8个字节，而UCS-2需要14个字节。

为此增加了Python字符串和Python解释器本身的开销，您的计算又变得有意义了。

当您以二进制模式（characters | s | o | l | u | ţ | i | e utf-8 |0x73 |0x6f |0x6c |0x75 |0xc5 0xa3|0x69 |0x65 ucs-2 |0x00 0x73|0x00 0x6f|0x00 0x6c|0x00 0x75|0x01 0x63|0x00 0x69|0x00 0x65）打开文件时，您不对字节进行解码，而是按原样使用它们。如果文件中有文本，这是有问题的（因为要处理数据，您迟早要将其转换为字符串，然后必须在其中进行解码），但是如果它确实是二进制数据，例如作为图像，很好（更好）。

此答案包含简化内容。谨慎使用。

为什么读取整个文件比在DISK上占用更多的RAM？

注意

背景

测试脚本

输出

1 个答案: