Speed up interval rounding #63245
Merged
Speed up interval rounding #63245
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
This speeds up date_histogram by precomputing the rounding points for date intervals like `10d`. The speedup for the rounding itself is between 18% (UTC many buckets) and 65% (US Eastern Time few buckets). 43% seems like it'd be pretty common: ``` Benchmark (count) (interval) (range) (zone) Mode Cnt Score Error Units before 10000000 10d 2000-10-28 to 2000-10-31 UTC avgt 10 130822390.700 ± 177466.657 ns/op before 10000000 10d 2000-10-28 to 2000-10-31 America/New_York avgt 10 189236837.930 ± 7958933.566 ns/op after 10000000 10d 2000-10-28 to 2000-10-31 UTC avgt 10 66413746.325 ± 1578834.032 ns/op after 10000000 10d 2000-10-28 to 2000-10-31 America/New_York avgt 10 65656941.375 ± 291608.870 ns/op before 10000000 2h 2000-10-28 to 2000-10-31 UTC avgt 10 130854975.013 ± 369133.702 ns/op before 10000000 2h 2000-10-28 to 2000-10-31 America/New_York avgt 10 165831615.257 ± 139074.982 ns/op after 10000000 2h 2000-10-28 to 2000-10-31 UTC avgt 10 107832636.671 ± 3502704.198 ns/op after 10000000 2h 2000-10-28 to 2000-10-31 America/New_York avgt 10 107608802.940 ± 979286.160 ns/op ``` Speedup for the date_histogram is likely to vary based on how much IO dominates the collection.
|
Pinging @elastic/es-analytics-geo (:Analytics/Aggregations) |
elasticmachine
added
the
Team:Analytics
|
I'm running performance tests locally to see what I see on some real data. |
|
The data that I have to run performance tests for this actually doesn't work well because it contains outliers which disable this optimization - there are some docs with dates in 1970 and some on 2050 but the bulk of them are around 2015 or something. That kind of thing defeats this optimization. So we're going to have to rely on the lower level performance test here. I'll have a think about outliers and how we can stop them from defeating the optimization. |
|
Thanks @not-napoleon ! |
nik9000
added a commit
to nik9000/elasticsearch
that referenced
this pull request
Oct 6, 2020
This speeds up date_histogram by precomputing the rounding points for date intervals like `10d`. The speedup for the rounding itself is between 18% (UTC many buckets) and 65% (US Eastern Time few buckets). 43% seems like it'd be pretty common: ``` Benchmark (count) (interval) (range) (zone) Mode Cnt Score Error Units before 10000000 10d 2000-10-28 to 2000-10-31 UTC avgt 10 130822390.700 ± 177466.657 ns/op before 10000000 10d 2000-10-28 to 2000-10-31 America/New_York avgt 10 189236837.930 ± 7958933.566 ns/op after 10000000 10d 2000-10-28 to 2000-10-31 UTC avgt 10 66413746.325 ± 1578834.032 ns/op after 10000000 10d 2000-10-28 to 2000-10-31 America/New_York avgt 10 65656941.375 ± 291608.870 ns/op before 10000000 2h 2000-10-28 to 2000-10-31 UTC avgt 10 130854975.013 ± 369133.702 ns/op before 10000000 2h 2000-10-28 to 2000-10-31 America/New_York avgt 10 165831615.257 ± 139074.982 ns/op after 10000000 2h 2000-10-28 to 2000-10-31 UTC avgt 10 107832636.671 ± 3502704.198 ns/op after 10000000 2h 2000-10-28 to 2000-10-31 America/New_York avgt 10 107608802.940 ± 979286.160 ns/op ``` Speedup for the date_histogram is likely to vary based on how much IO dominates the collection.
nik9000
added a commit
that referenced
this pull request
Oct 7, 2020
This speeds up date_histogram by precomputing the rounding points for date intervals like `10d`. The speedup for the rounding itself is between 18% (UTC many buckets) and 65% (US Eastern Time few buckets). 43% seems like it'd be pretty common: ``` Benchmark (count) (interval) (range) (zone) Mode Cnt Score Error Units before 10000000 10d 2000-10-28 to 2000-10-31 UTC avgt 10 130822390.700 ± 177466.657 ns/op before 10000000 10d 2000-10-28 to 2000-10-31 America/New_York avgt 10 189236837.930 ± 7958933.566 ns/op after 10000000 10d 2000-10-28 to 2000-10-31 UTC avgt 10 66413746.325 ± 1578834.032 ns/op after 10000000 10d 2000-10-28 to 2000-10-31 America/New_York avgt 10 65656941.375 ± 291608.870 ns/op before 10000000 2h 2000-10-28 to 2000-10-31 UTC avgt 10 130854975.013 ± 369133.702 ns/op before 10000000 2h 2000-10-28 to 2000-10-31 America/New_York avgt 10 165831615.257 ± 139074.982 ns/op after 10000000 2h 2000-10-28 to 2000-10-31 UTC avgt 10 107832636.671 ± 3502704.198 ns/op after 10000000 2h 2000-10-28 to 2000-10-31 America/New_York avgt 10 107608802.940 ± 979286.160 ns/op ``` Speedup for the date_histogram is likely to vary based on how much IO dominates the collection.
|
The backport of this didn't make the branch cut for 7.10 so it'll release with 7.11. |
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.
This speeds up date_histogram by precomputing the rounding points for
date intervals like
10d. The speedup for the rounding itself isbetween 18% (UTC many buckets) and 65% (US Eastern Time few buckets).
43% seems like it'd be pretty common:
Speedup for the date_histogram is likely to vary based on how much IO
dominates the collection.