Я на начальной стадии написания основного режима 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> ...)
проблемы:
- Хранение данных в потенциально огромной структуре, подобной этой, имеет какие-либо компромиссы производительности для системы? Я хотел бы избежать хранения посторонних данных, но я сделал то, что мог, и я не думаю, что набор данных в первую очередь настолько велик (для обычного использования), поскольку это всего лишь текст, читаемый человеком в разумных пропорциях. (Я планирую отбрасывать старые данные, используя время в начале списка; каждый наследует свое время последнего обновления от своих потомков и так далее по дереву. В какой степени должен происходить этот отбор: я не конечно.)
- Имеет ли хранение таких данных какие-либо компромиссы производительности для того, кто должен их использовать? То есть будут ли операции установки и извлечения страдать от размера списка?
Есть ли у вас другие предложения относительно того, как может выглядеть лучшая структура?
org); вставка в <!-- language: blah>случае необходимости (в зависимости от режима, в котором было выполнено редактирование кода); вроде того. Смотрите README на GitHub для получения дополнительной информации, и чувствовать себя наиболее приветствовать предложить функции. Чем больше я знаю об этом заранее, тем лучше его можно разработать. изменить, не говоря уже о сочетаниях клавиш Emacs;)