数组的TCL最大尺寸 [英] TCL max size of array
问题描述
我工作的工程应用，界面是用TCL TK。
一切正常，直到我需要使用（极）大阵。元件370.000.000，从2至10个字符的长度（线性生长）。</ P>的每个元素
我的问题是，¿在哪里大小限制TCL数组？
我一直在阅读和研究的唯一我发现是2GB字符串数据，但我不知道这是否是可靠的，因为它没有说明理由。
我做了一个实验：
设置LISTA [名单]
抓{
对于{集I 0} {$ I＆LT; 3.7亿} {增量我} {
lappend LISTA $ I
}
}
把$ I
返回$ I =在32位50.000.000或多或少的Windows 7
这是一个有点复杂来解释。 2GB的限制来自于低级别的内存分配器，其中有大小限制，因为它使用的签署的32位整数来形容多少内存来分配。那是在32位系统上很好，但它是一个开放的错误（这可能会被分配给我），它仍然在64位系统上真实的;在C API在正确的类型实际上是 ssize_t供（是的，仍然签署;负值用于信令），但修复它完全击毁了很多API，所以它需要一个主要版本的变化进行梳理。
但是列表的最大尺寸是另一回事。这是从根本上链接到的几件事情的组合。首先，有这意味着你可能无法可靠地获取列表256M以上元素的64位系统上可分配的内存结构（2GB的限制）的最大尺寸。再有就是分配的项目总数，但在实践中是较少的问题，特别是如果你居然把项目列表中多次（因为它们共享引用）。最后，还有串重新名单presentation的大小：如果你产生了很多，你这样做也无妨错，但是这将是你的榜样真正的限制因素，如果你在创造它（因为这将达到2GB限制越快）。
的实际的地步，你打的内存的限制可能较低，这取决于当你的系统开始拒绝请求分配内存。这一切都取决于操作系统，这往往立足于别人是怎么回事，在系统上的决定，所以它的难以置信的努力给予任何形式的一般规则那里。我的（64位，OSX）系统花了很长时间，但成功地运行您的样品code：
$ tclsh8.6
％的eval {
集LISTA [名单]
抓{
对于{集I 0} {$ I＆LT; 3.7亿} {增量我} {
lappend LISTA $ I
}
}
把$ I
}
3.7亿
％llength $ LISTA
3.7亿
未设置％LISTA
％ 出口
的 llength 是唯一的真正快捷的操作（因为它可以拉伸出长度列表中的元数据）。在取消设置花了很长时间。在退出是pretty快，但花了几秒钟。
I'm working on an engineering application, and the interface is written in TCL TK.
Everything went fine until I need to use a (extremely) large array. 370.000.000 of elements, each element from 2 to 10 characters length (linear grown).
My question is, ¿where is the size limit for TCL arrays? I've been reading and investigating and the only I've found is "2GB" of string data, but I dont know if it's reliable because it doesn't explain the reason.
I did an experiment:
set lista [list ]
catch {
for {set i 0} {$i < 370000000} {incr i} {
lappend lista $i
}
}
puts $i
returns $i = 50.000.000 more or less on a 32 bits Windows 7
It's a bit complicated to explain. The 2GB limit comes from the low-level memory allocator, which has a size limit because it uses a signed 32-bit integer to describe how much memory to allocate. That was fine on 32-bit systems, but it's an open bug (which might be assigned to me) that it's still true on 64-bit systems; the right type in the C API is actually ssize_t (yeah, still signed; negative values are used for signalling) but fixing it completely wrecks a lot of API, so it requires a major version change to sort out.
But the maximum size of a list is something else. That is fundamentally linked to a combination of a few things. Firstly, there's the maximum size of memory structure that can be allocated (the 2GB limit) which means that you probably can't reliably get more than 256M elements in a list on a 64-bit system. Then there's the total number of items allocated, though that's less of a problem in practice, particularly if you actually put items in the list multiple times (as they share references). Finally, there's the size of the string representation of the list: if you're generating that a lot, you're doing it wrong anyway, but that would be the real limiting factor in your example if you were creating it (as that will hit the 2GB limit sooner).
The actual point where you hit the memory limit might be lower, depending on when your system starts to deny requests to allocate memory. That's all up to the OS, which tends to base its decision on what else is going on on the system, so it's incredibly hard to give any kind of general rule there. My (64-bit, OSX) system took ages, but succeeded in running your sample code:
$ tclsh8.6
% eval {
set lista [list ]
catch {
for {set i 0} {$i < 370000000} {incr i} {
lappend lista $i
}
}
puts $i
}
370000000
% llength $lista
370000000
% unset lista
% exit
The llength was the only truly quick operation (since it could pull the length out of the list metadata). The unset took ages. The exit was pretty quick, but took a few seconds.
这篇关于数组的TCL最大尺寸的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
