方案效率结构

Question

我想知道我们的口译员是否在作弊以获得更好的表现。据我所知，方案中唯一真正的数据结构是缺陷单元。

显然，cons单元格可以制作简单的数据结构，如链表和树，但我认为在某些情况下可能会使代码变慢，例如，如果您想访问cadr的{​​{1}}一个东西。对于具有更多元素的数据结构，情况会变得更糟......

也就是说，方案car和cdr非常有效，以至于它比C ++中的寄存器偏移速度慢得多。

我想知道是否有必要实现一个分配本机内存块的特殊数据结构。类似于使用malloc的东西。我谈的是纯粹的计划，而不是与FFI有关的任何事情。

Answer 1

  

据我了解，方案中唯一真正的数据结构是缺点单元。

这根本不是真的。

R5RS，R6RS和R7RS方案所有包括向量和字节向量以及对/列表，它们是您提到的连续内存块。

另外，考虑Scheme是最小标准，并且各个Scheme实现倾向于提供比标准中存在的更多原语。例如，这些可以实现高效的I / O，并且如果您想要执行您正在使用的Scheme实现本身不支持的某些内容，许多Schemes也提供了一个FFI来调用C代码。

链接列表确实是一个相对较差的通用数据结构，但它们很简单，可以从前到后进行迭代，这在函数式编程中很常见。但是，如果您需要随机访问，那么您使用链接列表是正确的。

Answer 2

首先关闭。在Scheme中有许多原始类型和许多不同的复合类型甚至用户描述的类型。

在C ++中，内存模型以及值的存储方式是the standard的关键部分。在Scheme中，您无法访问语言内部作为标准，但实现可以使用更高比例的Scheme编写实现。

该标准不会干扰实现选择存储数据的方式，因此即使许多人通过在地址中嵌入原始值来模仿彼此，否则每个其他值都是堆上的对象，它不需要。使用pair作为向量的实现（C ++中的数组）正在推动它，如果不仅仅是一个有趣的恶作剧，它将成为一个非常不受欢迎的实现。

使用R6RS，您可以创建自己的类型，甚至可以使用records进行扩展：

(define-record-type (node make-node node?)
  (fields 
    (immutable value node-value)
    (immutable left node-left))
    (immutable right node-right)))

node?将是不相交的，因此除了使用构造函数#t创建的值之外，其他任何值都不会是make-node，并且这有3个字段而不是使用两个cons来存储相同的。

现在，在数组中存储相同类型的元素时，C ++可能具有默认优势，但您可以通过多种方式解决此问题。例如。使用您在this video about optimizing java for memory usage中看到的相同技巧。我本来可以通过对记录进行良好的数据建模来开始，并且当它们成为一个问题时相当担心性能。