Skip to content

Large speed ups in iterating over all mappings - #308

Merged
fitzgen merged 2 commits into
mozilla:masterfrom
fitzgen:split-is-slow
Jan 18, 2018
Merged

Large speed ups in iterating over all mappings#308
fitzgen merged 2 commits into
mozilla:masterfrom
fitzgen:split-is-slow

Conversation

@fitzgen

Copy link
Copy Markdown
Contributor

r? @tromey

This is beneficial for both the extant JS and the incoming wasm in #306.

Order of magnitude speed up iterating over all mappings by throwing a dumb LRU cache in front of the normalize function.

Ignore last commit in review -- all mechanical.

Comment threadlib/util.js Outdated
@@ -89,6 +89,25 @@ function normalize(aPath) {
var isAbsolute = exports.isAbsolute(path);

var parts = path.split(/\/+/);

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

nit: the call to path.split() hasn't been removed yet ;)

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

D'oh

Comment threadlib/util.js
const cache = [];

return function (input) {
for (var i = 0; i < cache.length; i++) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is this faster than Array.indexOf?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

We can't use indexOf here because the data in the array is an Object and so will be tested for pointer equality.

We could use Array.prototype.find, but now we're introducing functions and things, and the whole point of this code is to gain whatever control we can over execution, which higher-order-functions can be a bit anathema to.

@tromey

Copy link
Copy Markdown
Contributor

I couldn't load the "files changed" view for some reason, but this is r+ from me, with the comment in the first patch addressed. The thing about Array.indexOf is optional. Thanks!

`String.prototype.split` is slow with regexps. Writing out the C-style string
searching code makes us take .8x the time on the "iterate.already.parsed"
benchmark from the "wasm" branch.
With the old String.prototype.split:
Samples Total (ms) Mean (ms) Standard Deviation (ms)
50 325864.18 6517.28 162.15
With the new custom splitting:
Samples Total (ms) Mean (ms) Standard Deviation (ms)
50 257604.64 5152.09 221.19
We are almost always normalizing the same strings over and over again. Think
about when iterating over mappings: we are reconstructing each mapping's source,
but the mappings are in sorted order, and so will likely have the same source
every time.
This makes us take .09x the time that we used to take on the
"iterate.already.parsed" benchmark!!
Without the LRU cache:
Samples Total (ms) Mean (ms) Standard Deviation (ms)
50 257604.64 5152.09 221.19
With the new LRU cache:
Samples Total (ms) Mean (ms) Standard Deviation (ms)
50 23301.74 466.03 56.14
@fitzgen

Copy link
Copy Markdown
ContributorAuthor

Thanks for review!

@fitzgen

Copy link
Copy Markdown
ContributorAuthor

The queue for OSX machines in Travis is very long, going to go ahead and merge this now, since Linux is OK and it WFM on OSX locally.

@fitzgen
fitzgen merged commit 51cf770 into mozilla:masterJan 18, 2018
benthemonkey added a commit to benthemonkey/source-map that referenced this pull request Nov 5, 2018
benthemonkey added a commit to benthemonkey/source-map that referenced this pull request Nov 5, 2018
Sign up for freeto 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

@fitzgen@tromey@bnjbvr