Оптимальная структура данных для нашего собственного API

Я на начальной стадии написания основного режима Emacs для сети Stack Exchange ; если вы регулярно используете Emacs, это в конечном итоге принесет вам пользу.

Чтобы свести к минимуму количество обращений к API Stack Exchange (ограничено 10000 на IP в день) и быть просто ответственным гражданином, я хочу кэшировать информацию, которую я получаю из сети, и сохранять ее в памяти, ожидая быть доступным снова. Я действительно застрял в том, в какой структуре данных хранить эту информацию.

Очевидно, это будет список. Однако, как и в случае с любой структурой данных, выбор должен определяться тем, какие данные хранятся и каким образом они будут доступны. Что, я хотел бы иметь возможность хранить всю эту информацию в одном символе, например stack-api/cache. Итак, без дальнейших церемоний, stack-api/cacheэто список conses с последним обновлением:

`(<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> ...)

проблемы:

• Хранение данных в потенциально огромной структуре, подобной этой, имеет какие-либо компромиссы производительности для системы? Я хотел бы избежать хранения посторонних данных, но я сделал то, что мог, и я не думаю, что набор данных в первую очередь настолько велик (для обычного использования), поскольку это всего лишь текст, читаемый человеком в разумных пропорциях. (Я планирую отбрасывать старые данные, используя время в начале списка; каждый наследует свое время последнего обновления от своих потомков и так далее по дереву. В какой степени должен происходить этот отбор: я не конечно.)
• Имеет ли хранение таких данных какие-либо компромиссы производительности для того, кто должен их использовать? То есть будут ли операции установки и извлечения страдать от размера списка?

Есть ли у вас другие предложения относительно того, как может выглядеть лучшая структура?

Emacs lisp не оптимизирован для обработки данных; вам может быть полезно использовать Common Lisp для движка и Emacs только для презентации.

Даже если вы решите придерживаться Emacs Lisp, я предлагаю вам использовать структурированные данные ( eieio) вместо списков и хеш-таблицы вместо списков.