Skip to content
项目
群组
代码片段
帮助
当前项目
正在载入...
登录 / 注册
切换导航面板
P
pytensor
项目
项目
详情
活动
周期分析
仓库
仓库
文件
提交
分支
标签
贡献者
图表
比较
统计图
议题
0
议题
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
CI / CD
CI / CD
流水线
作业
日程
统计图
Wiki
Wiki
代码片段
代码片段
成员
成员
折叠边栏
关闭边栏
活动
图像
聊天
创建新问题
作业
提交
问题看板
Open sidebar
testgroup
pytensor
Commits
e43983b8
提交
e43983b8
authored
8月 21, 2012
作者:
steven-pigeon
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Addressed comments from pull requests (most of)
上级
1203f136
隐藏空白字符变更
内嵌
并排
正在显示
1 个修改的文件
包含
22 行增加
和
7 行删除
+22
-7
python-memory-management.rst
doc/tutorial/python-memory-management.rst
+22
-7
没有找到文件。
doc/tutorial/python-memory-management.rst
浏览文件 @
e43983b8
...
@@ -325,19 +325,22 @@ This small program creates a list with 1,000,000 ints (at 24 bytes each,
...
@@ -325,19 +325,22 @@ This small program creates a list with 1,000,000 ints (at 24 bytes each,
for ~24 million bytes) plus a list of references (at 8 bytes each, for ~8
for ~24 million bytes) plus a list of references (at 8 bytes each, for ~8
million bytes), for about 30MB. It then deep-copies the object (which
million bytes), for about 30MB. It then deep-copies the object (which
allocates ~50MB, not sure why; a simple copy would allocate only 8MB of
allocates ~50MB, not sure why; a simple copy would allocate only 8MB of
references). Freeing ``x`` with ``del`` frees the reference list, kills the
references, plus about 24MB for the objects themselves---so there's a large
associated objects, but lo!, the amount of memory only goes down by the
overhead here, maybe Python grew its heap preemptively). Freeing ``x`` with
number of references, because the list itself is not in a small objects'
``del`` frees the reference list, kills the associated objects, but lo!,
list, but on the heap, and the dead small objects remain in the free list,
the amount of memory only goes down by the number of references, because
and not returned to the interpreter's global heap.
the list itself is not in a small objects' list, but on the heap, and the
dead small objects remain in the free list, and not returned to the
interpreter's global heap.
In this example, we end up with *twice* the memory allocated, with 82MB,
In this example, we end up with *twice* the memory allocated, with 82MB,
while only one list necessitating about 30MB is returned. You can see why
while only one list necessitating about 30MB is returned. You can see why
it is easy to have memory just increase more or less surprisingly if we're
it is easy to have memory just increase more or less surprisingly if we're
not careful.
not careful.
\*
\* \*
Pickle
------
On a related note: is ``pickle`` wasteful?
On a related note: is ``pickle`` wasteful?
...
@@ -489,6 +492,18 @@ Memory consumption on writing is now much better. It still creates a lot of
...
@@ -489,6 +492,18 @@ Memory consumption on writing is now much better. It still creates a lot of
temporary small objects (for 60MB's worth), but it's not doubling memory
temporary small objects (for 60MB's worth), but it's not doubling memory
usage. Reading is comparable (using only marginally less memory).
usage. Reading is comparable (using only marginally less memory).
This particular example is trivial but it generalizes to strategies where
you don't load the whole thing first then process it but rather read a few
items, process them, and reuse the allocated memory. Loading data to a
Numpy array, for example, one could first create the Numpy array, then read
the file line by line to fill the array: this allocates one copy of the
whole data. Using pickle, you would allocate the whole data (at least)
twice: once by pickle, and once through Numpy.
Or even better yet: use Numpy (or PyTables) arrays. But that's a different
topic that is discussed in 'loading and saving' another tutorial in the
Theano/doc/tutorial directory.
\*
\*
\* \*
\* \*
...
...
编写
预览
Markdown
格式
0%
重试
或
添加新文件
添加附件
取消
您添加了
0
人
到此讨论。请谨慎行事。
请先完成此评论的编辑!
取消
请
注册
或者
登录
后发表评论