You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please describe the problem you are trying to solve.
Currently, only a subset of the API functions show up in the profiling, namely:
construction
initialize
advance
finalize
We further annotate the time spent in the solver.
solver.initialize
solver.advance
However, this time still includes preCICE API calls, which can be interesting for the user to know the runtime of.
setMeshVertex / setMeshVertices
setMesh (Singular + Plural)
readData (which may perform interpolation)
writeData
writeGradientData
getVertexIDsAndCoordinates
Downside is that this will make already inefficient singular versions even slower. (setMeshVertex, single-vertex reads and writes)
Describe the solution you propose.
Add events to the API calls (after rough input validation).
Big upside of using names in the API calls is that we can now directly use them to name the events:
Example for readData: Event e{fmt::format("readData.{}_{}", meshName, dataName)};
Describe alternatives you've considered
Only profile internals. The API layer is mostly pretty cheap and non-allocating.
For example: readData can be a copy if the t exists, a copy if we extrapolate, or an expensive BSpline interpolation with possible computation. The interpolation and the computation are more interesting measurements than the API itself.
Additional context
The user can also be the author of bindings, who may want to profile extra functionality e.g. in readData.
I had to manually add these events for precice/python-bindings#202
The attached trace-v3.json of this discourse post contains some of these events.
The text was updated successfully, but these errors were encountered:
Please describe the problem you are trying to solve.
Currently, only a subset of the API functions show up in the profiling, namely:
We further annotate the time spent in the solver.
However, this time still includes preCICE API calls, which can be interesting for the user to know the runtime of.
Downside is that this will make already inefficient singular versions even slower. (setMeshVertex, single-vertex reads and writes)
Describe the solution you propose.
Add events to the API calls (after rough input validation).
Big upside of using names in the API calls is that we can now directly use them to name the events:
Example for
readData
:Event e{fmt::format("readData.{}_{}", meshName, dataName)};
Describe alternatives you've considered
Only profile internals. The API layer is mostly pretty cheap and non-allocating.
For example:
readData
can be a copy if the t exists, a copy if we extrapolate, or an expensive BSpline interpolation with possible computation. The interpolation and the computation are more interesting measurements than the API itself.Additional context
The user can also be the author of bindings, who may want to profile extra functionality e.g. in readData.
I had to manually add these events for precice/python-bindings#202
The attached trace-v3.json of this discourse post contains some of these events.
The text was updated successfully, but these errors were encountered: