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.
This is a couple of fairly small optimizations. I'm fairly tentative about these, since I'm scared it might break something. In particular, caching the outer_bounds and outer_position properties seems risky. These all work well for me, but more testing would be good.
Reducing the amount of accesses to layout_needed might seem unimportant, and it might be, but in the well log plots this is being accessed several thousand times a second and takes about ~1% of the run time. Note how every single draw(), _draw(), _draw_dispatch(), and do_layout() call all check this property, and each time it is accessed, the property goes through all components in the container recursively. So if the hierarchy of containers got any deeper (it's only about 3 in my case), the number of checks could get quite ridiculous. This removes a few of them, but doesn't fix the overarching problem.
intersect_bounds, too, gets called surprisingly often and was very inefficient before since it would convert to a different representation of rectangles, intersect those, and then convert back.
The outer_bounds and outer_positions are accessed a lot (for is_in checks, largely) and accesses a bunch of other properties. This could take a couple percent of the runtime in my use cases. I'm worried that I haven't covered all the cases for the depends_on property and could risk breaking existing code this way.
Thoughts?