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

Cache ObjectMappers to prevent continual recursion during dynamic mapper building #103858

Closed

Conversation

benwtrent
Copy link
Member

@benwtrent benwtrent commented Jan 3, 2024

When building dynamic mappers, it is possible to recurse down the ObjectMapper tree more than once. If the ObjectMapper.Builder keeps rebuilding the objects every time, even if there is no change, the runtime increases significantly.

This commit addresses this by caching the ObjectMapper that is built by the Builder. Invalidating the cache when something is changed.

closes: #103011

@benwtrent benwtrent added >bug :Search Foundations/Mapping Index mappings, including merging and defining field types v8.12.1 v8.13.0 v8.11.4 labels Jan 3, 2024
@elasticsearchmachine
Copy link
Collaborator

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

@elasticsearchmachine elasticsearchmachine added the Team:Search Meta label for search team label Jan 3, 2024
@elasticsearchmachine
Copy link
Collaborator

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

Comment on lines +194 to +205
@Override
public final ObjectMapper build(MapperBuilderContext context) {
if (objectMapperCache != null) {
return objectMapperCache;
}
objectMapperCache = doBuild(context);
return objectMapperCache;
}

protected void clearObjectMapperCache() {
objectMapperCache = null;
}
Copy link
Member Author

Choose a reason for hiding this comment

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

At this point, I am not sure which is better. Doing this, or reverting: #90674

@javanna ^

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for pinging. I think reverting for now is our wisest option. Happy you have come to a similar conclusion, I think. Long term, we should reconsider what we want to do . Perhaps the updates to the benchmarks is something we do want to get in separately?

Copy link
Member Author

Choose a reason for hiding this comment

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

Perhaps the updates to the benchmarks is something we do want to get in separately?

Yes, I will open a separate PR. Its a small adjustment, but showed how we still hadn't addressed the performance issue.

@benwtrent benwtrent marked this pull request as draft January 3, 2024 19:32
elasticsearchmachine pushed a commit that referenced this pull request Jan 4, 2024
Reverts #90674

The revert is not perfectly clean as there are some minor adjustments to
account for later changes.

This is in contrast with:
#103858

closes: #103011
benwtrent added a commit to benwtrent/elasticsearch that referenced this pull request Jan 4, 2024
Reverts elastic#90674

The revert is not perfectly clean as there are some minor adjustments to
account for later changes.

This is in contrast with:
elastic#103858

closes: elastic#103011
benwtrent added a commit to benwtrent/elasticsearch that referenced this pull request Jan 4, 2024
Reverts elastic#90674

The revert is not perfectly clean as there are some minor adjustments to
account for later changes.

This is in contrast with:
elastic#103858

closes: elastic#103011
elasticsearchmachine pushed a commit that referenced this pull request Jan 4, 2024
Reverts #90674

The revert is not perfectly clean as there are some minor adjustments to
account for later changes.

This is in contrast with:
#103858

closes: #103011
elasticsearchmachine pushed a commit that referenced this pull request Jan 4, 2024
Reverts #90674

The revert is not perfectly clean as there are some minor adjustments to
account for later changes.

This is in contrast with:
#103858

closes: #103011
@benwtrent benwtrent closed this Jan 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Search Foundations/Mapping Index mappings, including merging and defining field types Team:Search Meta label for search team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Significant ingest performance regression while handling parsing dynamically added objects
4 participants