PERF.8 BimCraft: IFC geometry runs on the page thread — a 22.5 MB model blocks it for 4.3 s and peaks at 867 MB

Measured 2026-11-08 in /use (tools/perf/open-file.mjs): fixtures/showcase/bimcraft-water-treatment.ifc (22.5 MB, 115 elements, 683k triangles): the app says "Opened: 115 elements in 3.0 s", the page is quiet after 5.2 s, main-thread long tasks total 4.3 s (6 tasks, longest 1.66 s), JS heap 24 MB to 867 MB peak, 329 MB settled; zoom frames p95 500 ms on software GL.

Where: lib/ifc/open-async.js moves only the STEP scan to a worker (about 0.4 s of this); ifc-model.js:107 then runs api.StreamAllMeshes on the page: profile placement, booleans, triangulation (cc-ifc geometry.js) for every element. Plan: run the geometry pass in the same worker (post meshes back as transferred Float32/Uint32 arrays per batch of elements, draw as they arrive, so the first walls show in under a second), or at least yield between elements; release the per-element intermediate data (the 867 to 329 MB drop is GC finding it). Node figures for the same file: geometry 1.3 s single-threaded, so most of the 4.3 s is the page's extra work (three.js meshes, materials, the model tree). Wave 3 (apps-3d.md): 115 MB blocks 13.9 s (longest task 5.5 s), 201 MB blocks 18.5 s (8.2 s), heap about 1 GB per 100 MB of IFC (201 MB → 1.99 GB); a 1 GB IFC would need about 10 GB and does not fit. The first click adds 5 to 12 s for the inverse index (its own wave 3 row).