New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HV-1480 Performance and memory allocation improvements #845

Merged
merged 20 commits into from Oct 18, 2017
Commits on Sep 11, 2017
  1. HV-1480 Avoid initializing lists and maps in the common case where we

    gsmet committed Sep 5, 2017
    only have the default group
    
    Also optimize a bit the advanced case with groups.
  2. HV-1480 Avoid creating a list in the common case when we only have the

    gsmet committed Sep 5, 2017
    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.
  3. HV-1480 Avoid computing the hashCode if not necessary

    gsmet committed Sep 5, 2017
    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.
  4. HV-1480 Avoid removing and adding element to the node list

    gsmet committed Sep 5, 2017
    We can directly set the element in the list. It avoids some list
    resizing.
  5. HV-1480 Don't take into account the parent in hashCode and equals

    gsmet committed Sep 5, 2017
    Otherwise, we "compare" the whole path several times while comparing a
    path.
  6. HV-1480 Implement a copy on write strategy for the node list

    gsmet committed Sep 5, 2017
    It avoids copying the list when not strictly necessary
  7. HV-1480 Centralize the processed works in one single set

    gsmet committed Sep 5, 2017
    It avoids a lot of initialization/resizing and in the end it's more
    efficient.
  8. HV-1480 Setting the key or the index already makes the node iterable

    gsmet committed Sep 5, 2017
    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.
  9. HV-1480 We expect at least one node in the path so let's initialize the

    gsmet committed Sep 5, 2017
    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.
  10. HV-1480 Even if not strictly necessary, the leaf node should be

    gsmet committed Sep 5, 2017
    correctly set in all constructors
  11. HV-1480 Add another benchmark

    gsmet committed Sep 7, 2017
  12. HV-1480 Only set the property value if required

    gsmet committed Sep 8, 2017
    Only property and container node exposes it to users.
Commits on Oct 4, 2017