给出的问题陈述是 “你正在开发一个只有4 KB可用内存的嵌入式设备（ATM），你希望按照提取的金额（丢弃原始交易顺序）对2,000,000笔交易进行排序。”
对于这个问题陈述，据我说我们应该使用合并排序，这个排序算法有什么问题吗？
答案 0 :(得分：1)
您肯定在寻找 space 复杂度远小于O(n)的算法，因为2百万次交易可能需要超过4 KB ......
space 复杂性给出了相对于输入大小执行排序所需的内存空间量。有了这么低的可用内存，你就无法使用占用太多空间的算法。
合并排序是空格O(n)，因此您最好寻找其他内容。
像O(log n)这样的东西会很棒，因为例如，2百万的自然对数是〜15。
查看this table，哪个列表
最多为O(log n)空间。
答案 1 :(得分：1)
如果要应用任何类型的递归算法，您需要考虑参数的所需内存量（堆栈），并为递归的每个方法调用返回堆栈上的地址。 2.000.000意味着每种使用一种分治方法的算法将达到约21的递归深度。 这意味着即使是一个聪明的实现也需要为每个递归步骤的开销提供200字节（大约4000/21）的内存。
应该可以实现这种限制的几乎每一个就地排序算法。 E.g：
和其他（也是合并排序的变种应该是可能的in place merge sort）。
答案 2 :(得分：1)
两件事，一个空间复杂性和时间复杂性。由于你的问题特别限制了空间，我认为最好的解决最坏情况空间复杂度的问题。那些是，
如果性能是您应用程序中的一个问题，那么在上面的HeapSort和SmoothSort中可能会提供更好的性能。
由于空间复杂度
，MergeSort可能不适用于此方案答案 3 :(得分：0)
是的，存在一个问题：合并排序具有线性空间复杂性。这意味着它需要与您要排序的条目数成比例的内存量。
如果您的交易已经在内存中，那么您可能需要一个原位（或内存）算法，如quicksort或heapsort。否则，您必须使用@YoungHobbit建议的直接在磁盘上运行的算法。
答案 4 :(得分：0)
这是嵌入式系统的问题。它们的内存有限。
我的回答是2部分。
<强> 1。算法视角中的最佳排序
至少谈论使用bubbble，插入，选择排序是没有意义的，因为它们在内存和性能方面不是非常有效。
以下是一些具有最差时间和空间复杂性的高级排序。
快速排序，O（n n）---- O（n log（n））
合并排序，O（n * log（n））---- O（n）
Tim sort，O（n * log（n））---- O（n）
堆排序，O（n * log（n））---- O（1）
shell sort，O（n * log（n）^ 2）---- O（1）
Bucket sort，O（n * n）---- O（n）
基数排序，O（nk）---- O（n + k）
因此，由于您需要节省内存并加快处理时间，我相信堆排序将是最佳选择，因为在最坏的情况下它也可以在O（n * log（n））下运行和O（1）时间和空间的复杂性。
<强> 2。表现明智
由于高性能对于这种情况至关重要，因此您需要考虑代码优化，使用EEPROM 和扩展内存。