我们自己的API的最佳数据结构

我处于为Stack Exchange网络编写Emacs主要模式的早期阶段; 如果您定期使用Emacs，最终将使您受益。

为了最大程度地减少对Stack Exchange API的调用次数（每个IP每天最多10000次），并成为一个负责任的公民，我想缓存从网络收到的信息并将其存储在内存中，等待再次被访问。我真的对存储此信息的数据结构感到困惑。

显然，这将是一个列表。但是，与任何数据结构一样，必须由存储什么数据以及如何访问它们来确定选择。我希望能够将所有这些信息存储在单个符号中，例如stack-api/cache。因此，stack-api/cache事不宜迟，这里列出了最近更新提出的一些要点：

`(<csite> <csite> <csite>)

<csite>会在哪里

(1362501715 . <site>)

至此，我们所要做的就是定义一个简单的关联列表。当然，我们必须更深入。

每个<site>都是API参数列表（唯一），后跟一个列表问题：

`("codereview" <cquestion> <cquestion> <cquestion>)

<cquestion>您猜对了，每个问题的最新更新时间都是一个问题：

`(1362501715 <question>) (1362501720 . <question>)

<question>是question结构和答案列表的缺点（同样，以其上次更新时间为准）：

`(<question-structure> <canswer> <canswer> <canswer>

和`

`(1362501715 . <answer-structure>)

这个数据结构是可能最准确地描述为一棵树，但我不知道是否有更好的方法来做到这一点考虑的语言，的Emacs Lisp（这是不是所有的从Lisp的不同，你知道，爱在所有）。明确的提示可能是不必要的，但它可以帮助我的大脑更好地围绕它。我敢肯定<csite>，例如，它将变成

(<epoch-time> <api-param> <cquestion> <cquestion> ...)

顾虑：

这样将数据存储在潜在的巨大结构中，是否会对系统的性能进行权衡？我想避免存储无关的数据，但是我已经做了我能做的，并且我认为数据集最初并没有那么大（对于正常使用），因为它只是人类可读文本，而且比例合理。（我正计划使用列表顶部的时间来收集旧数据；每个数据源都从其子级继承其最后更新时间，然后沿树向下继承。该剔除应在多大程度上进行：我不是当然。）
像这样存储数据是否会对必须使用的数据进行性能折衷？也就是说，设置和检索操作是否会受到列表大小的影响？

关于更好的结构，您还有其他建议吗？

data-structures emacs

— 肖恩·艾瑞德
source

我为此+1，因为我真的很想这个模式

— Daniel Gratzer

@jozefg我也很想要—实习已经占用了我的大部分时间，但是一旦学校开始，就应该取得更多的进步。

— 肖恩·艾尔雷德

我很高兴安装了一个浏览器插件，使我可以使用Emacs填写文本框内容。您是否要让Emacs理解Wiki标记并显示格式化的文本？

— 凯文·克莱恩

@kevincline不，这个想法是，它只会执行功利性任务：本地问题存档；高级代码编辑（跳出到正确的主模式，类似于org）；<!-- language: blah>在必要时插入（取决于完成代码编辑的方式）；类似的东西。有关更多信息，请参见GitHub上的README，并且非常欢迎建议功能。我对这一点了解得越多，它的设计就越好。编辑更不用说emacs键盘绑定了；）

— 肖恩·阿雷德

Emacs lisp并未针对数据处理进行优化；您可能会发现将Common Lisp用于引擎并将Emacs仅用于演示是有利的。

即使您决定坚持使用Emacs Lisp，我还是建议您使用结构化数据（eieio）代替列表，并使用哈希表代替alists。

— sds
source