Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[8.8] [ResponseOps] optimize building ecsFieldMap (elastic#159251) (e…
…lastic#159313) # Backport This will backport the following commits from `main` to `8.8`: - [[ResponseOps] optimize building ecsFieldMap (elastic#159251)](elastic#159251) <!--- Backport version: 8.9.7 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Patrick Mueller","email":"[email protected]"},"sourceCommit":{"committedDate":"2023-06-08T14:06:01Z","message":"[ResponseOps] optimize building ecsFieldMap (elastic#159251)\n\nresolves https://github.com/elastic/kibana/issues/157772\r\n\r\nPreviously on my M1 Macbook, the `ecsFieldMap` constant takes about 170\r\nms to be created. It appears this is another case of `array::reduce()`\r\nand object spread causing performance issues.\r\n\r\nConverting to (essentially) a filter and map got the time down to 4 ms.\r\n\r\nSlightly critical even though this is only ever run once - because it's\r\nrun at startup time, and blocking everything else from running.\r\n\r\nSee:\r\n\r\n-\r\nhttps://www.richsnapp.com/article/2019/06-09-reduce-spread-anti-pattern\r\n-\r\nhttps://prateeksurana.me/blog/why-using-object-spread-with-reduce-bad-idea/","sha":"6e81ae83bc17b020684e3d206dbb696c225e9d1c","branchLabelMapping":{"^v8.9.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Alerting","release_note:skip","Team:ResponseOps","v8.9.0","v8.8.2"],"number":159251,"url":"https://github.com/elastic/kibana/pull/159251","mergeCommit":{"message":"[ResponseOps] optimize building ecsFieldMap (elastic#159251)\n\nresolves https://github.com/elastic/kibana/issues/157772\r\n\r\nPreviously on my M1 Macbook, the `ecsFieldMap` constant takes about 170\r\nms to be created. It appears this is another case of `array::reduce()`\r\nand object spread causing performance issues.\r\n\r\nConverting to (essentially) a filter and map got the time down to 4 ms.\r\n\r\nSlightly critical even though this is only ever run once - because it's\r\nrun at startup time, and blocking everything else from running.\r\n\r\nSee:\r\n\r\n-\r\nhttps://www.richsnapp.com/article/2019/06-09-reduce-spread-anti-pattern\r\n-\r\nhttps://prateeksurana.me/blog/why-using-object-spread-with-reduce-bad-idea/","sha":"6e81ae83bc17b020684e3d206dbb696c225e9d1c"}},"sourceBranch":"main","suggestedTargetBranches":["8.8"],"targetPullRequestStates":[{"branch":"main","label":"v8.9.0","labelRegex":"^v8.9.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/159251","number":159251,"mergeCommit":{"message":"[ResponseOps] optimize building ecsFieldMap (elastic#159251)\n\nresolves https://github.com/elastic/kibana/issues/157772\r\n\r\nPreviously on my M1 Macbook, the `ecsFieldMap` constant takes about 170\r\nms to be created. It appears this is another case of `array::reduce()`\r\nand object spread causing performance issues.\r\n\r\nConverting to (essentially) a filter and map got the time down to 4 ms.\r\n\r\nSlightly critical even though this is only ever run once - because it's\r\nrun at startup time, and blocking everything else from running.\r\n\r\nSee:\r\n\r\n-\r\nhttps://www.richsnapp.com/article/2019/06-09-reduce-spread-anti-pattern\r\n-\r\nhttps://prateeksurana.me/blog/why-using-object-spread-with-reduce-bad-idea/","sha":"6e81ae83bc17b020684e3d206dbb696c225e9d1c"}},{"branch":"8.8","label":"v8.8.2","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Patrick Mueller <[email protected]>
- Loading branch information