-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Lens] Performance refactoring for indexpattern fast lookup and Operation support matrix computation #82829
[Lens] Performance refactoring for indexpattern fast lookup and Operation support matrix computation #82829
Conversation
The profiling and measurements above have been tested on an IndexPattern of 4000+ fields. |
…xpattern-fields-lookup
Looking also at this portion of code, which seems to waste the conditional task away: https://github.com/elastic/kibana/pull/82829/files#diff-adf4f7cb4d70d7250d44841daef76d1c7a4794a06f7ca261510e1b1112e18bb4R283-R308 Maybe there's a missing |
I looked into the changes and it seems like the large performance bottleneck in the support operation matrix got introduced very recently here: f0023ed |
Pinging @elastic/kibana-app (Team:KibanaApp) |
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good, left some comments but nothing major
x-pack/plugins/lens/public/indexpattern_datasource/dimension_panel/bucket_nesting_editor.tsx
Show resolved
Hide resolved
fieldExists(existingFields, currentIndexPattern.title, field); | ||
|
||
function fieldNamesToOptions(items: string[]) { | ||
return items | ||
.map((field) => ({ | ||
label: fieldMap[field].displayName, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't seem like a good handling of the error case here (it could create entries without a label) - let's filter out all fields without entry in the field map instead before mapping
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would that happen? Fields are validated against the containsData
here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are not for all invocations - fieldNamesToOptions
is also called for empty fields in line 138 of this file.
@@ -37,16 +37,17 @@ export const getOperationSupportMatrix = (props: Props): OperationSupportMatrix | |||
|
|||
filteredOperationsByMetadata.forEach(({ operations }) => { | |||
operations.forEach((operation) => { | |||
// replace spread operator by regular push as it's performance wise faster |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Let's remove this comment, it won't make sense after the PR is merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea was to keep it to prevent future use of spread operator again
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, got confused by the wording. Can we go with // using mutating push instead of spread operator as it's faster
?
if (operation.type === 'field') { | ||
supportedOperationsByField[operation.field] = [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wylieconlon Replacing push with a spread here happened relatively recently in a refactor PR you did (splitting up the dimension editor). Is there any reason for preferring spreading?
x-pack/plugins/lens/public/indexpattern_datasource/indexpattern_suggestions.ts
Show resolved
Hide resolved
@@ -146,8 +146,8 @@ export function getAvailableOperationsByMetadata(indexPattern: IndexPattern) { | |||
|
|||
operationDefinitions.sort(getSortScoreByPriority).forEach((operationDefinition) => { | |||
if (operationDefinition.input === 'field') { | |||
indexPattern.fields.forEach((field) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how these changes improve the code - it's still nested to the same depth (plus addToMap
does not actually return something). Can you elaborate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a particular speed up here.
I did some small profiling and numbers are bit lower than with all the conditionals: seeing no harm in particular change I kept it, but it can easily reversed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with all the conditionals
Which conditionals do you mean? I wasn't aware this was a performance optimization, can you explain how it could speed things up? I think I'm missing something here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant "from the previous implementations with the if/else
conditionals".
It may be an anecdotal to my machine, so no strong opinion on these.
…dej611/kibana into feature/lens/indexpattern-fields-lookup
@elasticmachine merge upstream |
Tested in Chrome, I didn't find any problems with it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes LGTM, didn't test again. Thanks for addressing all the points!
💚 Build SucceededMetrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: |
…tion support matrix computation (elastic#82829) Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
…kibana into bootstrap-node-details-overlay * 'bootstrap-node-details-overlay' of github.com:phillipb/kibana: (49 commits) [Security Solution] Fix DNS Network table query (elastic#82778) [Workplace Search] Consolidate groups routes (elastic#83015) Adds cloud links to user menu (elastic#82803) [Security Solution][Detections] - follow up cleanup on auto refresh rules (elastic#83023) [App Search] Added the log retention panel to the Settings page (elastic#82982) [Maps] show icon when layer is filtered by time and allow layers to ignore global time range (elastic#83006) [DOCS] Consolidates drilldown pages (elastic#82081) [Maps] add on-prem EMS config (elastic#82525) migrate i18n mixin to KP (elastic#81799) [bundle optimization] fix imports of react-use lib (elastic#82847) [Discover] Add metric on adding filter (elastic#82961) [Lens] Performance refactoring for indexpattern fast lookup and Operation support matrix computation (elastic#82829) skip flaky suite (elastic#82804) Fix SO query for searching across spaces (elastic#83025) renaming built-in alerts to Stack Alerts (elastic#82873) [TSVB] Disable using top_hits in pipeline aggregations (elastic#82278) [Visualizations] Remove kui usage (elastic#82810) [Visualizations] Make the icon buttons labels more descriptive (elastic#82585) [Lens] Do not reset formatting when switching between custom ranges and auto histogram (elastic#82694) Fix ilm navigation (elastic#81664) ...
…na into alerts/stack-alerts-public * 'alerts/stack-alerts-public' of github.com:gmmorris/kibana: [Security Solution] Fix DNS Network table query (elastic#82778) [Workplace Search] Consolidate groups routes (elastic#83015) Adds cloud links to user menu (elastic#82803) [Security Solution][Detections] - follow up cleanup on auto refresh rules (elastic#83023) [App Search] Added the log retention panel to the Settings page (elastic#82982) [Maps] show icon when layer is filtered by time and allow layers to ignore global time range (elastic#83006) [DOCS] Consolidates drilldown pages (elastic#82081) [Maps] add on-prem EMS config (elastic#82525) migrate i18n mixin to KP (elastic#81799) [bundle optimization] fix imports of react-use lib (elastic#82847) [Discover] Add metric on adding filter (elastic#82961) [Lens] Performance refactoring for indexpattern fast lookup and Operation support matrix computation (elastic#82829) skip flaky suite (elastic#82804) Fix SO query for searching across spaces (elastic#83025) renaming built-in alerts to Stack Alerts (elastic#82873) [TSVB] Disable using top_hits in pipeline aggregations (elastic#82278) [Visualizations] Remove kui usage (elastic#82810) [Visualizations] Make the icon buttons labels more descriptive (elastic#82585) [Lens] Do not reset formatting when switching between custom ranges and auto histogram (elastic#82694) :
Summary
Due to new validation checks being added to the Lens UI while the user performs actions (see #81439 and #82607 ) some performance tweaks have been performed to speed up lookup operations for indexpattern fields and related operations.
getFieldByName
method to the Lens'Indexpattern
interface implementing a fast lookup mechanismindexpattern.fields.find()
instancegetOperationSupportMatrix
to be fastgetOperationSupportMatrix
to useSet
s instead of array for faster lookupsFixes #82243
the bigger contribution of performance comes from the refactor of
getOperationSupportMatrix
which is now taking at least 80% less time:Checklist