【问题标题】:RAM usage in dealing with numpy arrays and Python lists处理 numpy 数组和 Python 列表时的 RAM 使用情况
【发布时间】:2020-10-10 00:17:25
【问题描述】:

我有记忆问题,不明白为什么。我正在使用 Google Colab,它给了我 12GB 的 RAM,让我看看 RAM 的使用情况。

我正在从文件中读取np.array,并将每个数组加载到一个列表中。

database_list = list()
for filename in glob.glob('*.npy'):
  temp_img = np.load(filename)
  temp_img = temp_img.reshape((-1, 64)).astype('float32')
  temp_img = cv2.resize(temp_img, (64, 3072), interpolation=cv2.INTER_LINEAR)
  database_list.append(temp_img)

代码print("INTER_LINEAR: %d bytes" % (sys.getsizeof(database_list)))打印:

INTER_LINEAR:124920 字节

对于重新整形为 64x64、512x64、1024x64、2048x64 和 3072x64 的数组,它的值相同。但是,如果我将这些数组重新整形为 4096x64,则会出现错误,因为使用了太多 RAM。

对于 3072x64 的数组,我可以看到 RAM 使用率越来越高,然后又下降。

我的最终目标是将每个数组补零到 8192x64 的尺寸,但我之前的会话崩溃了;但这是另一个问题。

RAM 是如何使用的?为什么,如果数组有不同的维度,列表有相同的大小? python 是如何加载和操作这个文件的,这解释了 RAM 的使用历史?

编辑:

然后

sizeofelem = database_list[0].nbytes 
#all arrays have now the same dimensions MxN, so despite its content, they should occupy the same memory
total_size = sizeofelem * len(database_list)

工作和total_size反映了列表的正确大小?

【问题讨论】:

  • 因为保存每个 numpy 数组内容的数据保存在单独分配的内存块中。数组对象本身只是一堆元数据和指向数据缓冲区的指针,因此总是相同(小)大小。
  • @DanMašek 我添加了一个编辑;你能回应吗?然后我会结束这个问题。如果你能更彻底地解释你的答案,我会非常感激,即使现在很清楚。谢谢
  • 您在编辑中计算的是数组内容使用的内存总大小。它不包括数组元数据,也不包括与列表相关的任何内容。但是,一个 4096x64 的 32 位浮点数数组是 1 MiB,因此仅使用 total_size 就可以很容易地为您提供正确的估计值

标签: python numpy opencv google-colaboratory


【解决方案1】:

我有办法。

首先,正如Dan Mašek 所指出的,我正在测量数组使用的内存,这是一个指针集合(粗略地说)。测量实际内存使用情况:

(database_list[0].nbytes * len(database_list) / 1000000, "MB")

其中database_list[0].nbytes 是可靠的,因为database_list 中的所有元素都具有相同的大小。更准确地说,我应该添加数组元数据并最终添加链接到它的所有数据(例如,如果我将其他结构存储在数组中)。

为了减少对内存的影响,我应该知道我正在读取的数据类型,即 0-65535 范围内的值,所以:

database_list = list()
for filename in glob.glob('*.npy'):
  temp_img = np.load(filename)
  temp_img = temp_img.reshape((-1, 64)).astype(np.uint16)
  database_list.append(temp_img)

此外,如果我对存储在 database_list 中的数据进行一些计算,例如,对 0-1 范围内的值进行归一化,例如 database_list = database_list/ 65535.0(注意:database_list,作为一个列表,不支持该操作),我应该再做一次转换,因为 Python 将类型转换为 float64 之类的东西。

【讨论】:

    猜你喜欢
    • 2018-08-18
    • 2012-07-31
    • 2013-03-31
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-09-06
    • 2012-12-31
    • 1970-01-01
    相关资源
    最近更新 更多