Optimize entities
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Refactorización
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- clojure
- Área
- databases, performance
Línea de trabajo
Comienza leyendo la búsqueda actual de atributos de entidad, los índices eavt y btset y la implementación de Iter; revisa también el trabajo sobre conteos acotados en #226. Compara almacenar en caché todos los datoms de la entidad con conservar un Iter y define un fallback para conjuntos grandes de referencias. Se considera terminado cuando las búsquedas son más rápidas sin un uso problemático de memoria para entidades con muchas referencias.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Also partially dicussed on Slack:
Currently an attribute lookup on an entity does a search into the btset and then caches the result. This is inefficient since the all the attribute values are right next to each other in the eavt index.
Getting them all at once and storing them in a cache makes sense, but has huge problem:
- What if the entity has a many ref with many many references?
- What if the entity has MANY attributes
I think 2) is unlikely a use-case and can be ignored. However 1) is an issue.
Ideas:
- Save an
Iterinstance that represents(Datom. eid nil nil nil nil), ie, all Datoms belonging to an entity. This is fast to get. - Enhance
Iterto allow fast searching within anIter. This would mean we can avoid thecacheof an entity and just lookup in theIter. - For avoiding performance problems with 1) we could add a heuristic to fall back to the current implementation when the
countof anIteris "too large" (> 20??). For this implementbounded-countforIter. See #226
- Lenguaje dominante
- Clojure
- Estrellas
- 5.8k
- Forks
- 318
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de tonsky/datascript
-
Dificultad 4/5 3-5 días Aptitud para principiantes 42/100
tonsky/datascript#498 · 1 comentario ·
-
Datascript MCP ServerAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 10/100
tonsky/datascript#489 ·
-
Stack overflow when transacting :db.type/tupleAttrs with a :db.type/ref attr through :db.fn/callAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
tonsky/datascript#483 · 2 comentarios ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
tonsky/datascript#470 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
tonsky/datascript#441 · 1 comentario · 3 reacciones ·
Todos los issues de tonsky/datascript
Issues similares
-
.Needs Triage Priority:P3 Type:New Feature
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
metabase/metabase#83625 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
replikativ/datahike#1105 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 90/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
clj-commons/loom#166 ·
Los mantenedores suelen responder en 1 día