Profiling

Data Oriented C++

Plan to throw one away, you will anyhow

At the time of writing (2026-10-28) NoDOM is on its third implementation. The first was based on imgui-js. That initial implementation quickly broke down as the volume of data climbed, since it expresses app logic in TypeScript. So the second version rewrote the render engine logic in C++, but left data and layout as JSON objects. It was quicker than the first, but suffered from crossing the emscripten::val boundary too frequently. This second version could sustain frame rates of 10-15 per second. Unfortunately that's nowhere near good enough for smooth snappy interactions. So I took a deep breath, and started a second rewrite. I felt the need for speed, and these are the principles to which I adhered in the rewrite...

• Data Oriented C++: structure of arrays, zero copy zero alloc hot path, rectilinear data, minimal stack thrashing, no vfuncs
• Free the CPU by moving work to the GPU
• Serverisation: threading, logging, monitoring and work queues are good for the server side, so let's use them on the client too

As I rewrote the code I used Microsoft's PIX profiler from the Game Dev Kit. In the screenshot below you can see I was working on eliminating invocations of std::map::operator[] from the render hotpath. Removing copying and any IO from the hotpath yielded further gains. MSVC and PIX are a far more tractable diagnostic environment for debugging and profiling than wasm in Chrome; hence the existence of breadboard.exe