Implement optional profiling for export #1977
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Linked to armory3d/armsdk#16.
Combined with the PR above, you can now choose to run cProfile when exporting the scene. This will generate a file called
profile_exporter.prof
in the SDK directory with detailed information about the number of calls and the time taken by the functions called during export. This file can then be opened by tools such as SnakeViz to get a graphical representation of whats happening during export:Example use case:
This is the result when compiling the celshade example project, which takes a huge amount of time. About 3/4 of the time are taken away for the export of individual objects (and analyzing the results a bit more leads to the conclusion that the way bone animations are exported is horrendously slow because for each bone the entire scene is set to each frame resulting in a complete redrawing and recalculation of the scene).
This is a very small step for the Python side of things towards #870. The new
Profile
context manager can be used for other occasions as well and can even be nested, although it will mess a bit with the results. It should always be opt-in due to performance reasons.I've also added a new util function to get a preference setting or a default value if it doesn't exist, which makes many of the current
get_[something]()
functions obsolete (they are still used though, that's not part of this PR).