使用 QSet 来跟踪非常大的一组相当大的字符串是不是一个坏主意？每个字符串为 54 个字符（108 个字节）。该集合可能包含数千个条目（我不确定确切的数字）。 QSet 将仅用于插入和成员查询。
如果这是一个坏主意，我绝对愿意接受建议。我的 54 个字符串仅由 6 个不同的字符组成（例如“AAAAAAAAABBBBBBBBBCCCCCCCCCDDDDDDDDDEEEEEEEEEFFFFFFFFF”）。这似乎是一个很好的压缩候选者，也许？欢迎任何其他建议。
【问题讨论】：
标签： qt memory-management hash dataset compression
意识到通过使用内置集，您将根据数据的性质进行一些路径级压缩。当然，这取决于容器的实现。
查看有关基数树、数字搜索树、红黑树等的一些信息。您会发现您不需要存储每个字符串，而是存储模式。例如，让我们简化您的问题：我们只有 3 个字符，每个字符最多可以出现 2 次，每个字符串的长度为 6 个字符。三个可能的字符串是：
AABBCC、AABCBC 和 AACBCB
通过这些示例，我们最多可以使用 6 + 3 + 4 = 13 个节点，而不是完整的 18 个节点。不是很重要，但我也不知道你在做什么。与任何类型的压缩一样，您的前缀模式被重复使用的次数越多，您拥有的压缩就越多。
编辑： 数字 13 和 18 来自路径级压缩。例如，在直接 C（用于参数/讨论）中，如果我将字符串存储类实现为数组的包装器，我可能只会有一个字符指针数组，每个指针都引用内存中包含模式的点。在我上面给出的示例中，这需要 18 个字符（6 * 3 = 18）。加上数组的大小（假设 sizeof(char*) 为 4，我们的数组将占用 3 * 4 字节的存储空间 = 12 + 18 或 30 字节总共来存储我们的模式。
如果我将模式存储在某种数字搜索树中，我会做一个小的权衡。我的树中的节点将大于 1 个字节（节点中的字符 1 个字节，每个节点中的“下一个”指针 4 个字节，每个 5 个字节）。我们存储的第一个模式是 AABBCC。这是树中的 6 个节点。接下来是AABCBC。我们重用来自第一棵树的路径 AAB，并且只需要额外的 3 个节点用于 CBC。最后一个模式是 AACBCB。我们重用 AA，CBCB 需要 4 个新节点。这是总共 13 个节点 * 5 个字节 = 65 个字节的存储空间。但是，如果您的数据前缀中有很多长而重复的模式，那么您会看到一些前缀路径级压缩。
如果您不是这种情况，我会研究 Huffman 或 LZW 压缩。这将要求您构建一个模式字典，其中包含与它们相关的整数。压缩时，您构建字典并为文本中的每个模式创建整数 id。然后用整数 id 替换文本中的模式。解压缩时，你做相反的事情。我没有时间更详细地描述这些算法，因此您需要查找它们。
这是对简单性/时间的权衡。如果您的数据允许，请采用较短的方法并使用内置容器。如果没有，您将需要更适合您的数据的东西。
【讨论】：
我认为在其他类型的容器（例如 std::set、地图或向量）上使用 QSet 不会有任何额外的问题。如果您想知道内存不足，那可能取决于您需要存储多少个字符串，以及是否有一种方法可以更简洁地对它们进行编码。 （例如，如果字符总是以相同的顺序出现但相对长度不同，则存储每个字符的长度而不是所有字符。）但是，即使这些字符串中的 50,000 个也只有 5 MB 左右，其中 500,000 个存储空间仅为 50 MB，不考虑存储开销，这在现代机器上属于中等内存量。
【讨论】：
QSet 听起来确实是个好主意。它基本上只是一个哈希表，它可以动态优化它的桶大小。完美。
另一个压缩密钥的建议： 将其视为 base-6 数字字符串（认为 A=0、B=1、... F=5）并将其转换为二进制 (int)。
QByteArray ba("112"); // instead of "BBC"
int num = ba.toInt(0, 6 /*base*/); // num == 44
6^3
【讨论】：
根据您之前的评论：“在我的字符串中，总是有 54 个字符，每个字符总是有 9 个。顺序是唯一改变的东西。”
那么不要存储原始字符串。您可以将它们压缩成实际使用的 6 个字符，然后将它们制作成一个 QSet。一个简单的压缩是 {a,b,c,d,e,f}，如果事先知道字符集（并且只有这 6 个字符），您甚至可以将内容打包成一个 16 位整数。
【讨论】：