Split out of #322 (p6-s8).
Observation
Both asset lookups are linear scans with a string compare per entry, and both are
now on paths a user can grow without limit:
props::model(std::string_view) — scans the model table
(core/src/assets/prop_meshes.gen.cpp:882-890, and after p6-s8 the project
overlay ahead of it in core/src/assets/prop_registry.cpp). Called per
object, per mesh build from core/src/mesh/mesh_builder.cpp:651, and again
per batch from editor/src/render/scene_builder.cpp:228-253 — which carries
its own note that a linear scan is fine for "~14 bundled models".MaterialCatalog::find_material — scans the definition vector, after stripping
one of three accepted prefixes (editor/src/render/material_catalog.cpp:79-92).
With 26 bundled props and 5 bundled materials this is not worth a hash map. With
a project that has imported a few hundred assets, build_object_instances over
an OSM district becomes O(objects × models) in string compares.
Why this is deliberately not urgent
Nothing here is known to be slow. This issue exists so the trade-off is
recorded rather than rediscovered, and it should be closed by a measurement even
if the measurement says "no change needed".
p7-s4 taught the governing lesson the expensive way: the OSM import's
super-linear build cost (#502)
was found by a scale bench, not by reading the code, and the fix is still gated
on profiling first. Apply the same order here.
Scope
- Measure first. Extend an existing scale harness with a project carrying
~500 imported prop models and ~100 materials, and report where the time goes.
- Only if the scans are material: an id → index map behind both lookups, rebuilt
when the project overlay is replaced. Neither public signature changes —
props::model() returns the same pointer with the same lifetime, and
find_material keeps accepting all three spellings.
- If the scans are not material, close this with the numbers in a comment.
That is a successful outcome, not a wasted issue.
Split out of #322 (
p6-s8).Observation
Both asset lookups are linear scans with a string compare per entry, and both are
now on paths a user can grow without limit:
props::model(std::string_view)— scans the model table(
core/src/assets/prop_meshes.gen.cpp:882-890, and afterp6-s8the projectoverlay ahead of it in
core/src/assets/prop_registry.cpp). Called perobject, per mesh build from
core/src/mesh/mesh_builder.cpp:651, and againper batch from
editor/src/render/scene_builder.cpp:228-253— which carriesits own note that a linear scan is fine for "~14 bundled models".
MaterialCatalog::find_material— scans the definition vector, after strippingone of three accepted prefixes (
editor/src/render/material_catalog.cpp:79-92).With 26 bundled props and 5 bundled materials this is not worth a hash map. With
a project that has imported a few hundred assets,
build_object_instancesoveran OSM district becomes O(objects × models) in string compares.
Why this is deliberately not urgent
Nothing here is known to be slow. This issue exists so the trade-off is
recorded rather than rediscovered, and it should be closed by a measurement even
if the measurement says "no change needed".
p7-s4taught the governing lesson the expensive way: the OSM import'ssuper-linear build cost (#502)
was found by a scale bench, not by reading the code, and the fix is still gated
on profiling first. Apply the same order here.
Scope
~500 imported prop models and ~100 materials, and report where the time goes.
when the project overlay is replaced. Neither public signature changes —
props::model()returns the same pointer with the same lifetime, andfind_materialkeeps accepting all three spellings.That is a successful outcome, not a wasted issue.