为简单起见，假设我们有一组个人联系人，第一个键是联系人姓名，还有一些子键，包括电话号码、地址、电子邮件、备注和出生日期
可以在内存中的数组中保存多少联系人而不会遇到性能问题？
作为参考，这将在运行 Debian Linux 的 512MB RAM 的旧机器上运行，因此资源稀缺
【问题讨论】：
标签： livecode
我也有兴趣知道这个问题的答案..不过我打算在我的应用程序上做一些测试......自动填充数组真的很容易。
global MyTestArray
repeat with x = 1 to 1000000
put uuid("random") into MyTestArray[x]["key1"]
put uuid("random") into MyTestArray[x]["key2"]
end repeat
给你的处理程序使用时间：
on TimedHandler
local start_time
put the milliseconds into start_time
// your handler that reads the array
put the milliseconds into end_time
answer (the milliseconds - start_time) / 1000
end TimedHandler
【讨论】：
随着数组的增加，您不会发现减速太多。在理想情况下，数组不会因为数据量的增加而变慢；它只会通过添加数百万个键来减慢速度。
换句话说，如果您的阵列有几 GB 的数据，并且您的计算机是具有足够内存的 64 位计算机，那么您的计算机根本不会变慢。如果您有一台 32 位机器并且您正在加载超过 4 GB 的数据，它将大量使用虚拟内存并且您会发现速度明显变慢。
由于您的数组有更多键，因此找到正确键的搜索例程可能需要更多时间，但只要您的数据库中的联系人少于几十亿（我假设 2^32 个联系人，但我没有检查确切的数字）我预计任何减速都是可以接受的。
但是，由于您表示使用的是具有 512MB 内存的旧机器，因此数据大小可能会成为问题。最大的问题是最终你的数据栈可能会大于可用内存的大小。 Debian 将占用大约一半的物理内存，这意味着您有 256MB 的另一半可用于其他应用程序，包括您的联系人数据库。如果您的应用使用漂亮的 GUI，您的应用将很快需要超过 256MB 的内存，并且严重依赖虚拟内存，从而导致速度变慢。
此外，数组并不总是最好的解决方案。首先，您最好使用 SQLite。 SQLite 具有非常快速的专用搜索例程，比任何使用数组的 LiveCode 例程都快。其次，使用简单列表的repeat for each line 循环有时比repeat for each key 循环更快，因为for each line 直接访问数据，而repeat for each key 首先循环遍历键，然后仍然需要访问数组以检查什么是在该键的元素中。
【讨论】：