Estoy en las primeras etapas de escribir un modo principal de Emacs para la red Stack Exchange ; Si usa Emacs regularmente, esto lo beneficiará al final.
Para minimizar la cantidad de llamadas realizadas a la API de Stack Exchange (con un límite de 10000 por IP por día) y para ser un ciudadano generalmente responsable, quiero almacenar en caché la información que recibo de la red y almacenarla en la memoria, esperando Se accede nuevamente. Estoy realmente atascado en cuanto a qué estructura de datos almacenar esta información.
Obviamente, será una lista. Sin embargo, como con cualquier estructura de datos, la elección debe determinarse por qué datos se almacenan y cómo se accederá a ellos. Qué, me gustaría poder almacenar toda esta información en un solo símbolo como stack-api/cache. Entonces, sin más preámbulos, stack-api/cachehay una lista de cones clave por última actualización:
`(<csite> <csite> <csite>)
donde <csite>estaría
(1362501715 . <site>)
En este punto, todo lo que hemos hecho es definir una lista de asociación simple . Por supuesto, debemos ir más profundo .
Cada uno <site>es una lista del parámetro API (único) seguido de una lista de preguntas:
`("codereview" <cquestion> <cquestion> <cquestion>)
Cada uno <cquestion>es, lo adivinaste, una desventaja de preguntas con su último tiempo de actualización:
`(1362501715 <question>) (1362501720 . <question>)
<question>es una desventaja de una questionestructura y una lista de respuestas (nuevamente, consed con su última hora de actualización):
`(<question-structure> <canswer> <canswer> <canswer>
y `
`(1362501715 . <answer-structure>)
Esta estructura de datos es probable que se describe con mayor precisión como un árbol, pero no sé si hay una forma mejor de hacer esto teniendo en cuenta el idioma, Emacs Lisp (que no es tan diferente de la Lisp que conocemos y amamos en absoluto ) . Es probable que los condes explícitos sean innecesarios, pero ayudan a que mi cerebro se adapte mejor. Estoy bastante seguro de que <csite>, por ejemplo, simplemente se convertiría en
(<epoch-time> <api-param> <cquestion> <cquestion> ...)
Preocupaciones
- ¿El almacenamiento de datos en una estructura potencialmente enorme como esta tiene algún compromiso de rendimiento para el sistema? Me gustaría evitar almacenar datos extraños, pero he hecho lo que pude y no creo que el conjunto de datos sea tan grande en primer lugar (para uso normal) ya que todo es solo texto legible por humanos en proporción razonable. (Estoy planeando eliminar datos antiguos usando los tiempos al principio de la lista; cada uno hereda su última actualización de sus hijos y así sucesivamente en el árbol. En qué medida este sacrificio debería tener lugar: no estoy seguro.)
- ¿El almacenamiento de datos como este tiene una compensación de rendimiento para lo que debe usar? Es decir, ¿las operaciones de configuración y recuperación sufrirán por el tamaño de la lista?
¿Tiene alguna otra sugerencia sobre cómo podría ser una mejor estructura?
org); insertar <!-- language: blah>cuando sea necesario (dependiendo del modo en que se realizó la edición de código); cosas como esas. Ver el README en GitHub para obtener más información, y sentir más bienvenidos a sugerir características. Cuanto más sepa sobre esto de antemano, mejor se puede diseñar. editar sin mencionar las combinaciones de teclas de emacs;)