Optimize entities

オープン
#227 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
リファクタリング
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
clojure
領域
databases, performance

調査の方向性

まず、現在のエンティティ属性ルックアップ、eavt インデックスと btset インデックス、および Iter の実装を読み、#226 の bounded-count に関する作業も確認してください。すべてのエンティティ datom をキャッシュする場合と Iter を保持する場合を比較し、大規模な参照セット向けの fallback を定義してください。多くの参照を持つエンティティで、メモリ使用量に問題を生じさせずにルックアップが高速化されれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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:

  1. What if the entity has a many ref with many many references?
  2. 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 Iter instance that represents (Datom. eid nil nil nil nil), ie, all Datoms belonging to an entity. This is fast to get.
  • Enhance Iter to allow fast searching within an Iter. This would mean we can avoid the cache of an entity and just lookup in the Iter.
  • For avoiding performance problems with 1) we could add a heuristic to fall back to the current implementation when the count of an Iter is "too large" (> 20??). For this implement bounded-count for Iter. See #226
主要言語
Clojure
スター
5.8k
フォーク
318
30日以内にマージされた PR はありません

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

tonsky/datascript のほかの issue

tonsky/datascript の issue をすべて見る

似ている issue

Clojure の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。