getItemsOfCategories is O(items × regexes) per call — category index makes repeated calls faster #248

Summary

getItemsOfCategories tests every regex against every item's category on every call:

for (let index = 0; index < this._model.categoriesLength(); index++) {
  const currentCategory = this._model.categories(index);
  ...
  for (const categoryRegex of categories) {
    if (categoryRegex.test(currentCategory)) { ... }
  }
}

That is O(items × regexes) per call. Callers tend to invoke it repeatedly (e.g. once per filter/query), so on large models this becomes a fixed ~1 s tax per call.

Measurements (real IFC-derived fragments model, 43 MB, ~1.5M items, 23 categories)

With a lazily built category → localIds Map over the immutable flatbuffer data (keyed by buffer identity so it rebuilds if the buffer is regenerated), regexes are tested once per distinct category name instead of once per item:

Results verified byte-identical (including result key order and id order); edit-request handling (created/updated/deleted items) unchanged. Memory cost of the index is roughly one number per item plus the category strings (~10–20 MB on this model).

Design question before a PR

I have a working, tested branch ready (perf/category-index). One open question: the VirtualPropertiesController constructor already iterates all items and stores each item's category in the _items map, so the index could alternatively be built there (or derived from _items) instead of lazily on first use. Happy to open the PR with whichever placement you prefer.

Related to #245 / #246 — same profiling session on real-world models where bulk property queries were the bottleneck.