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

roll our own format func #13

Merged
merged 3 commits into from
Mar 19, 2016
Merged

roll our own format func #13

merged 3 commits into from
Mar 19, 2016

Conversation

davidmarkclements
Copy link
Member

this isn't ready for acceptance, more the beginning of an experiment

I've taken core's util format, altered as follows:

  1. accept single param called "args", must be an array
  2. do not support non-string args for first arg (util format does this, but who uses that??)
  3. convert syntax to conform to standard linting

No conclusive savings as yet, but format is not inlining - target text too big

As an experiment I minified it, which solves target text too big, but instead we get: "target AST is too large [early]"

Possibly decomposing into smaller funcs is the solution here, needs more tinkering

@davidmarkclements
Copy link
Member Author

we also need benchmarks for multiple args and then for multiple args that use interpolation

once #8 is merged we can add multi-arg to benchmarks folder

@davidmarkclements
Copy link
Member Author

rolled out separate module: http://npm.im/quick-format

benchPinoInterpolateAll*10000: 398.659ms
benchPinoInterpolateAll2*10000: 399.629ms
benchPinoInterpolateExtra*10000: 1321.408ms
benchPinoInterpolateExtra2*10000: 445.608ms
benchPinoInterpolateAll*10000: 369.683ms
benchPinoInterpolateAll2*10000: 387.859ms
benchPinoInterpolateExtra*10000: 1301.741ms
benchPinoInterpolateExtra2*10000: 444.020ms

The main trick is in using stringify instead of inspect in the format function, that's it.

Whilst there's a 20ms diff with core util.format after 20000 ops in cases where we don't have trailing params, overall the perf benefits are huge.

I did rewrite the function using a str.split(/%/) approach, and managed to get the function to inline, but it turned out to be 30ms slower on average than the original - regardless of inlining (flamgraph showed that the bottleneck was the C functions resulting from str.split(/%/). So went back to the core function with a couple of tweaks (mainly, stringify, and cache f.length).

davidmarkclements pushed a commit that referenced this pull request Mar 19, 2016
@davidmarkclements davidmarkclements merged commit 61b6409 into master Mar 19, 2016
davidmarkclements pushed a commit that referenced this pull request Mar 19, 2016
davidmarkclements pushed a commit that referenced this pull request Mar 19, 2016
@davidmarkclements davidmarkclements deleted the roll-our-own-format branch April 7, 2016 11:22
@github-actions
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant