When a client tells you a single operation in their production software takes “a few minutes, sometimes more,” the instinct is to reach for a profiler and start looking at the slowest function. That’s a reasonable first step, but on a recent engagement it wasn’t enough on its own - the real story only showed up once we plotted processing time against model complexity.

The symptom wasn’t a slow function, it was a slow curve

The application in question generates a 3D model of a busbar and then animates a bending machine acting on it. Operators reported that both steps got noticeably slower as orders got more complex, but the complaints were inconsistent - sometimes fast, sometimes painfully slow. That inconsistency was the first clue: if a single function were simply slow, the wait would scale predictably with model size. Instead, we were looking at something closer to exponential growth.

We built a test matrix spanning models from 10 to 300 holes and 1 to 3 bends, and measured time spent in each stage: model loading, hole generation, animation frame rendering, and collision validation. The pattern that emerged was clear once visualized - processing time grew non-linearly with hole count, while bend count had almost no effect. At 300 holes, 3D model generation alone took over 13 minutes.

Non-linear growth almost always means an algorithmic problem, not a hardware one

Once we could see the curve, the root cause was easier to isolate: holes were being created sequentially, one geometry operation at a time, with a full rebuild of the collision model after every single change. That’s an O(n²)-shaped problem hiding behind what looked like “just a big model.” No amount of hardware upgrades would have fixed it - the fix had to be algorithmic.

The recommendation was to replace sequential hole creation with a single batched geometry operation, cache collision validation instead of rebuilding it on every change, and move both model and animation generation off the UI thread so operators aren’t blocked waiting for a full preview. Projected impact: a 75-85% reduction in processing time across the board.

The general lesson

If a performance complaint is inconsistent rather than uniformly slow, don’t just profile the slowest run - plot time against the variable that’s actually changing between “fast” and “slow” cases. A shape in that curve will usually point you straight at the algorithm doing unnecessary repeated work, long before you need to touch infrastructure.