Each Overload now copies and renames all of the functions it needs, which improves debugging and profiling. For example, consider a call to broaden. On the left, what the stack trace currently looks like on master, on the right, what it looks like with this PR.
Each function contains the Overload's name, in this case broaden, even for those that are inherited from the parent, in this case abstract_clone.
The type on which the function operates is also included in the name, between square brackets, which is valuable information.
Source location information is fully preserved, only the name is changed.
The function <name>.entry creates the initial state and does the postprocessing.
The function <name>.dispatch finds the right function to call and calls the wrapper if there is one. It is much simpler than Overload.__call__ used to be.
The SVG produced by --profile-svg is now much, much cleaner because there is no longer a "super-node" named Overload.__call__ with 500 arrows coming from and to it, and each Overload has its very own set of nodes.
This PR is based on #343
Each Overload now copies and renames all of the functions it needs, which improves debugging and profiling. For example, consider a call to
broaden
. On the left, what the stack trace currently looks like on master, on the right, what it looks like with this PR.broaden
, even for those that are inherited from the parent, in this caseabstract_clone
.<name>.entry
creates the initial state and does the postprocessing.<name>.dispatch
finds the right function to call and calls the wrapper if there is one. It is much simpler thanOverload.__call__
used to be.--profile-svg
is now much, much cleaner because there is no longer a "super-node" namedOverload.__call__
with 500 arrows coming from and to it, and each Overload has its very own set of nodes.