Introduce a PathBuilder #850
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
our current snapshot
We can directly set the element in the list. It avoids some list resizing.
only have the default group Also optimize a bit the advanced case with groups.
default violation Also optimize a bit the concatenation of the default violation and the custom ones to avoid creating a list too small and resize it each time.
A lot of NodeImpls are created during the build of the path and some of them are simply discarded as they are "modified" (NodeImpl are immutable so we create a new) further away. Thus we better avoid building the hashCode each time.
Otherwise, we "compare" the whole path several times while comparing a path.
It avoids copying the list when not strictly necessary
It avoids a lot of initialization/resizing and in the end it's more efficient.
So we don't need to do it twice. Note that this change uncovers the fact that in ConstraintValidatorContext, calling atKey() or atIndex() makes the node iterable. It was already the case before and I think it's acceptable. It brings its own performance improvements as it avoids initializing 1 NodeImpl and creating 1 copy of the Path.
list with one element It doesn't seem necessary to consider more elements as the list will be copied when new nodes will be added.
correctly set in all constructors
Only property and container node exposes it to users.
gunnarmorling
force-pushed
the
HV-1480
branch
from
aa68993
to
da77077
Compare
|
Hey @gsmet, what should we do about this one? Would you like to pursue the mutable/immutable split for paths and nodes at this time? If not, you could at least integrate my first commit and we should be good to go once you've addressed that one remark about a hash code. On the split above, instead of using |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Hey @gsmet, this is a small experiment based on your perf improvement work. You pointed out that the allocation of nodes and paths is a problem and I agree.
We went for the immutable approach back in the day as we often had issues with paths which were referenced e.g. in a constraint violation and then be altered later on in the course of subsequent validation of other constraints. I think the best way forward would be to separate mutable and immutable path and node types. The engine would in general work with the mutable representations and only "freeze out" an immutable reference when needed (constraint violation creation, storing processed path).
As a quick attempt, this PR is doing this very hackishly for paths, could you check whether it already makes a noticable difference? I'd expect a bigger difference when doing the same for nodes, but an early check may be useful to see whether it's in the right direction or not.