Dead-End: Very slow exception handling #11
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.
building as release and running in that mode, we completely get rid of the exception cost:

superseded details
I am trying to figure out why running a very basic python node that just returns all categories runs incredibly slow:
This is the content of the node - it is extremely simple and only calls the Dynamo category wrapper about a thousand times:

Initially I incorrectly assumed that I can just add a "bad category ids list" and improve the performance on consecutive runs. That however made zero difference to the overall performance (before vs after):
It still took over 13 seconds to run this single node. I then looked at the flame graph and realized that the extra 13 seconds of computing come purely from throwing the exceptions (look at the lines throwing the exceptions):
If we don't throw exceptions and just return nulls, that completely negates the slowdown:
Now, clearly we don't want to do that, because it breaks the overall functionality. But what can we do to avoid the cost? I know that exceptions are slow but they should not be this slow. Is the problem in the underlying Dynamo core VM or is it somewhere else? Do you have any further observations on this?