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

fix(pluginutils): improve regex performance #1753

Merged
merged 1 commit into from
Sep 22, 2024

Conversation

bluwy
Copy link
Contributor

@bluwy bluwy commented Jul 29, 2024

Rollup Plugin Name: pluginutils

This PR contains:

  • bugfix
  • feature
  • refactor
  • documentation
  • other

Are tests included?

  • yes (bugfixes and features will not be merged without tests)
  • no

Breaking Changes?

  • yes (breaking changes will not be merged unless absolutely necessary)
  • no

If yes, then include "BREAKING CHANGES:" in the first commit message body, followed by a description of what is breaking.

List any relevant issue numbers:
n/a

Description

Refactors some regex to use non-capturing groups (as captured groups are a little slower), and use regexp.prototype.exec instead of string.prototype.match for perf.

For the former change, it's hard to use an online tool to measure as the difference is quite small, but here's a local file you can copy using tinybench that you can run:

File
import { Bench } from 'tinybench'

const b = new Bench({ iterations: 1000 })

const choices = ['FunctionDeclaration', 'ClassDeclaration', 'VariableDeclaration', 'Identifier']
const strs = Array.from({ length: 10 }).map(_ => choices[Math.floor(Math.random() * choices.length)])

b.add('non-capture', () => {
  strs.forEach(s => { /(?:Function|Class)Declaration/.test(s) })
})

b.add('capture', () => {
  strs.forEach(s => { /(Function|Class)Declaration/.test(s) })
})

await b.warmup();
await b.run();

console.table(b.table());

node18.20.3 results:

┌─────────┬───────────────┬─────────────┬────────────────────┬──────────┬─────────┐
│ (index) │   Task Name   │   ops/sec   │ Average Time (ns)  │  Margin  │ Samples │
├─────────┼───────────────┼─────────────┼────────────────────┼──────────┼─────────┤
│    0    │ 'non-capture' │ '5,088,404' │ 196.5252384844669  │ '±0.63%' │ 2544203 │
│    1    │   'capture'   │ '4,831,673' │ 206.96762775341406 │ '±0.67%' │ 2415837 │
└─────────┴───────────────┴─────────────┴────────────────────┴──────────┴─────────┘

For the latter change, I've benchmarked this at lukeed/polka#210 which you can run the perf.link test for the results too.

@bluwy bluwy requested a review from shellscape as a code owner July 29, 2024 03:23
@@ -91,7 +91,7 @@ const dataToEsm: DataToEsm = function dataToEsm(data, options = {}) {

let maxUnderbarPrefixLength = 0;
for (const key of Object.keys(data)) {
const underbarPrefixLength = key.match(/^(_+)/)?.[0].length ?? 0;
const underbarPrefixLength = /^(_+)/.exec(key)?.[0].length ?? 0;
Copy link
Contributor

@benmccann benmccann Aug 26, 2024

Choose a reason for hiding this comment

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

I would expect here and in the other that perhaps it'd be better to move the regex declaration outside the method declaration so that it doesn't have to be recompiled each method invocation and each iteration of this loop

The same would be true of your other PR as well

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Something I've found over time is that it doesn't necessarily help with perf by hoisting it out. Engines these days are able to optimize it, and in most cases only yield very small gains. This was also discussed at lukeed/polka#210

Copy link
Contributor

Choose a reason for hiding this comment

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

the discussion there suggests the one place it matters is in loops, so it might still be worth changing here, but not in the other locations?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah perhaps we can try that here, but I'd prefer to have a benchmark on that first before making the change though

@shellscape shellscape changed the title perf(pluginutils): improve regex performance fix(pluginutils): improve regex performance Sep 22, 2024
Copy link
Collaborator

@shellscape shellscape left a comment

Choose a reason for hiding this comment

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

Going to merge this. I think this is a micro optimization to begin with, so not going to ask for additional optimizations on top of that. Please keep in mind that these tools typically run in environments with enough computing power that micro perf improvements barely have an impact.

@shellscape shellscape merged commit 184d81a into rollup:master Sep 22, 2024
10 checks passed
@bluwy bluwy deleted the perf-pluginutils-regex branch September 23, 2024 08:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants