Je suis aux premiers stades de l'écriture d'un mode majeur Emacs pour le réseau Stack Exchange ; si vous utilisez Emacs régulièrement, cela vous sera finalement bénéfique.
Afin de minimiser le nombre d'appels passés à l'API de Stack Exchange (plafonné à 10000 par IP par jour) et d'être simplement un citoyen généralement responsable, je souhaite mettre en cache les informations que je reçois du réseau et les stocker en mémoire, en attendant de être à nouveau accessible. Je suis vraiment coincé quant à la structure de données dans laquelle stocker ces informations.
De toute évidence, ce sera une liste. Cependant, comme pour toute structure de données, le choix doit être déterminé par les données stockées et la manière dont elles seront accessibles. Quoi, je voudrais pouvoir stocker toutes ces informations dans un seul symbole tel que stack-api/cache. Donc, sans plus tarder, stack-api/cachevoici une liste de conses saisis par la dernière mise à jour:
`(<csite> <csite> <csite>)
où <csite>serait
(1362501715 . <site>)
À ce stade, tout ce que nous avons fait est de définir une liste d'association simple . Bien sûr, nous devons aller plus loin .
Chacun <site>est une liste du paramètre API (unique) suivie d'une liste de questions:
`("codereview" <cquestion> <cquestion> <cquestion>)
Chacun <cquestion>est, vous l'aurez deviné, un contre de questions avec leur dernière mise à jour:
`(1362501715 <question>) (1362501720 . <question>)
<question>est un inconvénient d'une questionstructure et d'une liste de réponses (encore une fois, avec leur dernière heure de mise à jour):
`(<question-structure> <canswer> <canswer> <canswer>
et `
`(1362501715 . <answer-structure>)
Cette structure de données est probablement le plus précisément décrit comme un arbre, mais je ne sais pas s'il y a une meilleure façon de le faire compte tenu de la langue, Emacs Lisp (qui est pas si différent du Lisp que vous connaissez et l' amour du tout ) . Les conses explicites sont probablement inutiles, mais cela aide mon cerveau à mieux s'en sortir. Je suis à peu près sûr qu'un <csite>, par exemple, se transformerait en
(<epoch-time> <api-param> <cquestion> <cquestion> ...)
Préoccupations:
- Le stockage de données dans une structure potentiellement énorme comme celle-ci a-t-il des compromis de performances pour le système? Je voudrais éviter de stocker des données superflues, mais j'ai fait ce que j'ai pu et je ne pense pas que le jeu de données soit si grand en premier lieu (pour une utilisation normale) car ce n'est que du texte lisible par l'homme dans une proportion raisonnable. (Je prévois de supprimer les anciennes données en utilisant les heures en tête de liste; chacune hérite de l'heure de la dernière mise à jour de ses enfants et ainsi de suite dans l'arborescence. Dans quelle mesure cette élimination devrait avoir lieu: je ne suis pas sûr.)
- Le stockage de données comme celle-ci a-t-il des compromis de performances pour ceux qui doivent les utiliser? Autrement dit, les opérations de définition et de récupération souffriront-elles de la taille de la liste?
Avez-vous d'autres suggestions sur ce à quoi pourrait ressembler une meilleure structure?
la source
org); insérer<!-- language: blah>si nécessaire (selon le mode dans lequel l'édition de code a été effectuée); des trucs comme ça. Voir le README sur GitHub pour plus d' informations, et se sentent plus les bienvenus à proposer des fonctionnalités. Plus j'en sais d'avance, mieux cela peut être conçu. modifier pour ne pas mentionner les raccourcis clavier emacs;)Réponses:
Emacs lisp n'est pas optimisé pour le traitement des données; vous pourriez trouver avantageux d'utiliser un Common Lisp pour le moteur et Emacs pour la présentation uniquement.
Même si vous décidez de vous en tenir à Emacs Lisp, je vous suggère d'utiliser des données structurées (
eieio) au lieu de listes et des tables de hachage au lieu d'alistes.la source