← Back to team overview

kicad-developers team mailing list archive

Interesting data about inline performance

 

Disclaimer: absolutely not scientific data, to be taken as qualitative.

I was tracking an issue with memgrind (on another project) and got an
idea; so I did a trial run of pcbnew under callgrind (a profiling tool),
to see where the hot spots were (especially during display). The
workload was opening a board, and zooming on an area until a specific
region was fullscreen. Recorded runtime of about 7E9 Ir (instructions,
I think...)

Suprisingly the hottest function was BOARD_CONNECTED_ITEM::GetNetCode (a
really trivial accessor) with about 400E6 Ir, TRACK::GetBestInsertPoint
(332E6 Ir), NETINFO_ITEM::GetNet() (280E6 Ir, another trivial accessor).
After these with 200E6 Ir the dreaded hypot from libm (__hypot_finite,
to be exact); IIRC that was because of the line clipping code or
something like that.

GetBestInsertPoint in the workload is called during load and IIRC is
O(n) on the segment count; not interesting since it's 'one shot'.
Interesting to know how hard is to keep the segment list sorted, anyway.

In short, 5% of the time is spent looking for a int member :P however,
a lot of that time was spent during calls to GetBestInsertionPoint;
anyway: did the obvious optimization (put inline in the class
declaration), and recompiled...

Well, time spent in that call gone down to 280E6 Ir. Didn't expect
these call to be so expensive!

Conclusion: inlines these days are more effective than in the past. Good
data structures however still are better...

Side note: disabling instrumentation during board load and only
profiling the display... well hypot_finite and
GetPointToLineSegmentDistance still wins. The old profiling did by Vesa
is still valid (the line clipper is the culprit).

-- 
Lorenzo Marcantonio
Logos Srl