Up to 3.5× faster CAD structure reading

R&D results measured on an internal test build. Not yet shipped in a stable release.

Reading the CAD structure is the operation a PLM user triggers most often, and the one they feel most. It is also where cost accumulates invisibly: not inside a heavy algorithm, but across thousands of redundant calls that each look harmless in isolation.

In this R&D cycle we profiled the read path for all three CAD systems we support and rebuilt the target build. These are the measured results.

Autodesk Inventor — 1.7× to 2.1×

The dominant cause was structural redundancy: the same document was opened and scanned an average of 2.26 times within a single operation. Added to that, we were reading .PropId, a value the downstream flow never consumed. With the duplicate scan and the unused property removed, the gain lands between 1.7× and 2.1× depending on assembly depth. COM calls dropped by 50%.

SOLIDWORKS — 3.5×

Two bottlenecks compounded here. The code performed a complete feature walk whose result was never used, and every individual COM call into SOLIDWORKS carried roughly 15.6 ms of latency. The problem was never processing time; it was the number of times we crossed the COM boundary. Cutting the calls down to what was actually needed reduced read time by a factor of 3.5, with 68% fewer COM calls.

Solid Edge — 2.0×

The reader retrieved the value of 52 properties per document. Ten were actually used; the remaining 42 were read and discarded. On our reference assembly, read time went from 7.17 / 6.61 / 6.63 s to 4.02 / 4.01 / 4.00 s across three runs. COM calls dropped by 60%.

Same output, byte for byte

A performance number on its own is not worth much in a PLM. The first question any engineering manager should ask is what was given up to get it.

The answer here is nothing. The verification suite compares the full document flat list and the resulting structure before and after the change: 23 items against 23 items, identical in both. The output is byte-for-byte identical. These changes remove work that was never needed — they do not approximate, cache away, or defer anything.

The method matters more than the result

None of these were bugs. The software worked, the data was correct, the tests passed. They were sediment: code that grew over years, where every individual addition was reasonable in its own context and nobody had measured the whole in a long time.

That is why we treat periodic profiling as ordinary maintenance rather than an exceptional intervention. A reliable PLM is not just one that never loses data. It is one that responds in predictable time as the assembly grows.

Status and next steps

These changes currently live on the test build. Before they reach a stable release we will validate that the results hold against real customer scenarios, where configuration variety and bill-of-materials depth challenge assumptions that hold up easily in controlled conditions. We will publish the post-integration numbers even if they come in lower than the figures reported here.

Why this matters to us

OdooPLM is open source. Our stated goal is for it to become the most reliable PLM in the Odoo ecosystem, and one of the best anywhere. Milestones like this add no line items to a price list, but they are exactly what separates a tool people use every day from one they merely tolerate.

We will keep publishing the results of this work, including the embarrassing parts. Discovering that we were scanning the same document 2.26 times is not good news. Having found it is.