[DI] Improve performance of algorithm to find probe scriptId

[watson]

Warning: High risk of bikeshedding!

This might very well be overkill, but while I was refactoring this code recently, I was thinking of ways to use a Map instead of an array to store the reference between the script URL and the script ID.

This is the algorithm that I came up with.

This is not a very hot code-path as it's only hit every time a new probe is added. So it's not really necessary. So in the end this comes down to code readability and maintainability: And I can't really determine if it makes the code more readable/maintainable or worse.

What do you think?

[watson]

• [DI] Improve performance of algorithm to find probe scriptId #4729 👈 (View in Graphite)
• [DI] Add stack trace to log probe results #4727 : 1 other dependent PR (#4728 )
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

Overall package size

Self size: 7.21 MB
Deduped: 62.61 MB
No deduping: 62.89 MB

Dependency sizes

| name | version | self size | total size | |------|---------|-----------|------------| | @datadog/native-appsec | 8.1.1 | 18.67 MB | 18.68 MB | | @datadog/native-iast-taint-tracking | 3.1.0 | 12.27 MB | 12.28 MB | | @datadog/pprof | 5.3.0 | 9.85 MB | 10.22 MB | | protobufjs | 7.2.5 | 2.77 MB | 5.16 MB | | @datadog/native-iast-rewriter | 2.4.1 | 2.14 MB | 2.23 MB | | @opentelemetry/core | 1.14.0 | 872.87 kB | 1.47 MB | | @datadog/native-metrics | 2.0.0 | 898.77 kB | 1.3 MB | | @opentelemetry/api | 1.8.0 | 1.21 MB | 1.21 MB | | jsonpath-plus | 9.0.0 | 580.4 kB | 1.03 MB | | import-in-the-middle | 1.11.2 | 112.74 kB | 826.22 kB | | msgpack-lite | 0.1.26 | 201.16 kB | 281.59 kB | | opentracing | 0.14.7 | 194.81 kB | 194.81 kB | | pprof-format | 2.1.0 | 111.69 kB | 111.69 kB | | @datadog/sketches-js | 2.1.0 | 109.9 kB | 109.9 kB | | semver | 7.6.3 | 95.82 kB | 95.82 kB | | lodash.sortby | 4.7.0 | 75.76 kB | 75.76 kB | | lru-cache | 7.14.0 | 74.95 kB | 74.95 kB | | ignore | 5.3.1 | 51.46 kB | 51.46 kB | | int64-buffer | 0.1.10 | 49.18 kB | 49.18 kB | | shell-quote | 1.8.1 | 44.96 kB | 44.96 kB | | istanbul-lib-coverage | 3.2.0 | 29.34 kB | 29.34 kB | | rfdc | 1.3.1 | 25.21 kB | 25.21 kB | | tlhunter-sorted-set | 0.1.0 | 24.94 kB | 24.94 kB | | limiter | 1.1.5 | 23.17 kB | 23.17 kB | | dc-polyfill | 0.1.4 | 23.1 kB | 23.1 kB | | retry | 0.13.1 | 18.85 kB | 18.85 kB | | jest-docblock | 29.7.0 | 8.99 kB | 12.76 kB | | crypto-randomuuid | 1.0.0 | 11.18 kB | 11.18 kB | | koalas | 1.0.2 | 6.47 kB | 6.47 kB | | path-to-regexp | 0.1.10 | 6.38 kB | 6.38 kB | | module-details-from-path | 1.0.3 | 4.47 kB | 4.47 kB |

_{🤖 This report was automatically generated by heaviest-objects-in-the-universe}

[pr-commenter]

Benchmarks

Benchmark execution time: 2024-10-02 10:34:06

Comparing candidate commit d506517 in PR branch watson/DEBUG-2605/script-id-algo with baseline commit 4d2f5b8 in branch master.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 260 metrics, 6 unstable metrics.

[rochdev]

So it's not really necessary. So in the end this comes down to code readability and maintainability: And I can't really determine if it makes the code more readable/maintainable or worse.

I think readability is down a bit and performance is up a bit, but not to an extent where I'd argue one way or the other, so if you prefer that version then LGTM.

The base branch was changed.

[watson]

There isn't much difference in the performance. Here's a benchmark on Node.js 22.9.0 of 10.000 entries (the same in both the array and the map) where the key being searched for is in the middle:

Array x 23,873 ops/sec ±3.26% (97 runs sampled)
Map x 25,972 ops/sec ±0.92% (98 runs sampled)
Fastest is Map

Benchmark source: https://gist.github.com/watson/c0119480b1be6fa647be302de670ce15

The main difference I think is that there's fewer and simpler objects being created in memory for the Map implementation.