Skip to content
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

[Profiling] Reduce GC pressure #93590

Merged

Conversation

danielmitterdorfer
Copy link
Member

With this commit we reduce GC pressure in the profiling plugin by:

  • Presizing collections to the correct size.
  • Avoiding copying data needlessly by already using the collection type required by call sites.

With this commit we reduce GC pressure in the profiling plugin by:

* Presizing collections to the correct size.
* Avoiding copying data needlessly by already using the collection type
  required by call sites.
@danielmitterdorfer danielmitterdorfer added >enhancement :Search/Search Search-related issues that do not fall into other categories v8.7.1 labels Feb 8, 2023
@elasticsearchmachine elasticsearchmachine added Team:Search Meta label for search team v8.8.0 labels Feb 8, 2023
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-search (Team:Search)

@elasticsearchmachine
Copy link
Collaborator

Hi @danielmitterdorfer, I've created a changelog YAML for you.

Copy link
Member

@benwtrent benwtrent left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure how much pressure is relieved without there being measurements to back up the changes.

But just a few comments on the Map presizing.

Comment on lines +396 to +397
this.executables = new ConcurrentHashMap<>(executableCount);
this.stackFrames = new ConcurrentHashMap<>(stackFrameCount);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have to handle the "load facter" in maps.

You need to do something similar to org.elasticsearch.common.util.Maps here (I would say add a newConcurrentMapWithExpectedSize method there...)

    static int capacity(int expectedSize) {
        assert expectedSize >= 0;
        return expectedSize < 2 ? expectedSize + 1 : (int) (expectedSize / 0.75 + 1.0);
    }

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the comment. I thought so as well but if you look at the constructor of ConcurrentHashMap that is not necessary. It is considering the load factor (0.75) already:

https://github.com/openjdk/jdk/blob/c92a7deba50cbf5e283d1bd0ef5f2d6f8a4fc947/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L898

if (j < capacity) {
Arrays.fill(output, j, capacity, 0);
}
return List.of(output);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it being unmodifiable is important, use this. But Arrays.asList will probably do less copying as it will simply wrap the underlying array.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, good point. I've pushed e604f66.

int slices
) {
this.stackTracePerId = new ConcurrentHashMap<>(stackTraceCount);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need to handle the map LoadFactor here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see above.

Copy link
Member

@benwtrent benwtrent left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am sure you have done this, but it would be good to see a measurement showing the improvement this change makes.

Perf changes without measurements don't mean much IMO.

@danielmitterdorfer
Copy link
Member Author

Thanks for the review!

I am sure you have done this, but it would be good to see a measurement showing the improvement this change makes.

Yes, I did measurements. Admitted, the benefit is not huge: I see around 1% less young GCs with this change. However, we have tens of thousands of items to retrieve and we know the exact number upfront and to me this is a prime example where we should presize the respective collections instead of letting them grow.

@danielmitterdorfer danielmitterdorfer merged commit 9f4457c into elastic:main Feb 9, 2023
@danielmitterdorfer danielmitterdorfer deleted the profiling-presize-coll branch February 9, 2023 15:57
@danielmitterdorfer danielmitterdorfer added auto-backport-and-merge Automatically create backport pull requests and merge when ready v8.7.0 and removed auto-backport-and-merge Automatically create backport pull requests and merge when ready labels Feb 10, 2023
danielmitterdorfer added a commit to danielmitterdorfer/elasticsearch that referenced this pull request Feb 10, 2023
With this commit we reduce GC pressure in the profiling plugin by:

* Presizing collections to the correct size.
* Avoiding copying data needlessly by already using the collection type
  required by call sites.
elasticsearchmachine pushed a commit that referenced this pull request Feb 10, 2023
With this commit we reduce GC pressure in the profiling plugin by:

* Presizing collections to the correct size.
* Avoiding copying data needlessly by already using the collection type
  required by call sites.
saarikabhasi pushed a commit to saarikabhasi/elasticsearch that referenced this pull request Apr 10, 2023
With this commit we reduce GC pressure in the profiling plugin by:

* Presizing collections to the correct size.
* Avoiding copying data needlessly by already using the collection type
  required by call sites.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>enhancement :Search/Search Search-related issues that do not fall into other categories Team:Search Meta label for search team v8.7.0 v8.7.1 v8.8.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants