Question

为简单起见，我们说有一系列个人联系人，第一个关键是联系人姓名，还有一些子项，包括电话号码，地址，电子邮件，备注和出生日期

可以在内存中的数组中保存多少联系人而不会遇到性能问题？

供参考，这将在运行Debian Linux的512MB RAM的旧机器上运行，因此资源稀缺

Answer 1

我也有兴趣了解这个问题的答案。但是我会在我的应用程序上做一些测试......它很容易自动填充数组。

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

Answer 2

随着阵列的增加，你不会发现太慢。在理想情况下，阵列不会因数据量增加而减慢;它只会通过添加数百万个密钥来减慢速度。

换句话说，如果您的阵列有几千兆字节的数据，并且您的计算机是具有足够内存的64位计算机，那么您的计算机根本不会放慢速度。如果您有一台32位计算机并且您正在加载超过4 GB的数据，那么它将大量使用虚拟内存，您将看到显着的减速。

由于您的数组有更多的键，找到正确键的搜索例程可能需要更多的时间，但只要您的数据库中的联系人少于几十亿（我会假设2 ^ 32个联系人但我没有检查确切的数字）我预计任何减速都不会达到可接受的幅度。

但是，由于您指示使用512MB RAM的旧机器，因此数据大小可能会成为问题。最大的问题是最终您的数据堆栈可能大于可用内存的大小。 Debian将占用大约一半的物理内存，这意味着你有256MB的另一半可用于其他应用程序，包括你的联系人数据库。如果你的应用程序使用了一个漂亮的GUI，你的应用程序将很快需要超过256MB的内存，并且它将严重依赖虚拟内存，导致它变慢。

此外，阵列并不总是最佳解决方案。首先，您最好使用SQLite。 SQLite具有非常快速的专用搜索例程，比使用数组的任何LiveCode例程都快。其次，使用简单列表的repeat for each line循环有时比repeat for each key循环更快，因为for each line直接访问数据，而repeat for each key首先循环键，然后仍然需要访问数组以检查该键元素中的内容。

在性能下降之前，可以在阵列中存储多少信息？

2 个答案: