Skip to content
This repository has been archived by the owner on Dec 5, 2019. It is now read-only.

perf(src/index): regression caused by parsing source maps individually #287

Closed
wants to merge 1 commit into from

Conversation

lojjic
Copy link

@lojjic lojjic commented May 4, 2018

See issue #286

This approach reverts to not using a separate cache object, but being careful about lazily instantiating the SourceMapConsumer only when we know it is needed.

In my project's build, this took the number of instantiated SourceMapConsumer objects from 1418 down to 21.

@jsf-clabot
Copy link

jsf-clabot commented May 4, 2018

CLA assistant check
Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.


Jason Johnston seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

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

Bad solution avg on memory usage increase on ~25%, let use map instead weakmap

@lojjic
Copy link
Author

lojjic commented May 5, 2018

If you feel this was a "bad" solution, then you really won't like using a Map. At least this approach gives the opportunity for the SourceMapConsumers to be garbage collected as soon as each results handler finishes; using a Map would give no such opportunity, forcing them all to be kept in memory for the lifetime of the plugin.

I'm not sure exactly how you're measuring "avg on memory usage", or what baseline you're comparing against.

@alexander-akait
Copy link
Member

alexander-akait commented May 5, 2018

@lojjic local tests, in near future i will do pr with benchmark npm command. We need source map only when we have warnings/errors. Right now your solution always try to parse source maps even i don't have warning and error. I.E. increase memory/cpu usage when i don't need this.

@alexander-akait
Copy link
Member

Just replace WeakMap on Map it is allow to find golden way for all (who has errors/warnings and who has not)

@lojjic
Copy link
Author

lojjic commented May 5, 2018

Right now your solution always try to parse source maps

That is not true, check the diff. Line 201 after the change.

warning,
file,
inputSourceMap,
sourceMap,
Copy link
Member

@alexander-akait alexander-akait May 5, 2018

Choose a reason for hiding this comment

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

Also sourceMap can be undefined here, because warning !== error (and parsing in catch block doesn't execute)

Copy link
Member

@alexander-akait alexander-akait May 5, 2018

Choose a reason for hiding this comment

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

/cc @lojjic yep, my mistake, but if no error(s) - no source map

Copy link
Member

Choose a reason for hiding this comment

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

again mistake, sorry, very tired

Copy link
Author

Choose a reason for hiding this comment

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

I'm not following you. sourceMap can be null, if there is no valid inputSourceMap, but that's expected AFAICT.

Copy link
Author

Choose a reason for hiding this comment

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

Ah, ok! No worries.

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

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

Hm, looks very good, let's add test:

  1. source map is good and we have warning
  2. source map is broken and we have warning
  3. source map is good and we have error
  4. source map is broken and we have error

To ensure we have expected behaviour

@alexander-akait
Copy link
Member

Also i investigate why benchmark increase memory usage on ~25%

@michael-ciniawsky michael-ciniawsky changed the title Fix performance regression caused by parsing sourcemaps on every warning/error perf(src/index): regression caused by parsing source maps on every warning/error May 5, 2018
@michael-ciniawsky michael-ciniawsky added this to the 1.2.6 milestone May 5, 2018
Copy link
Member

@michael-ciniawsky michael-ciniawsky left a comment

Choose a reason for hiding this comment

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

@lojjic Thx

@@ -187,11 +171,15 @@ class UglifyJsPlugin {

tasks.push(task);
} catch (error) {
let sourceMap = null;
Copy link
Member

Choose a reason for hiding this comment

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

\n

@@ -208,14 +196,20 @@ class UglifyJsPlugin {
const { file, input, inputSourceMap, commentsFile } = tasks[index];
const { error, map, code, warnings, extractedComments } = data;

// Create source map if needed
let sourceMap = null;
Copy link
Member

Choose a reason for hiding this comment

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

\n

@michael-ciniawsky michael-ciniawsky changed the title perf(src/index): regression caused by parsing source maps on every warning/error perf(src/index): regression caused by parsing source maps individually May 5, 2018
@alexander-akait
Copy link
Member

/cc @lojjic friendly ping

@lojjic
Copy link
Author

lojjic commented May 14, 2018

Thanks for the bump. I understand the desire to fill in the test coverage for those scenarios you mentioned, if they were previously missing.

I've glanced at the tests and I'd definitely have to come up to speed with how the whole plugin works in context as well as how your tests are structured. Given my current time constraints I wouldn't expect that to happen in the next couple weeks.

@alexander-akait
Copy link
Member

@lojjic thanks for answer, i will try to find time on writing tests

@alexander-akait
Copy link
Member

Close in favor #305

Thanks!

@michael-ciniawsky michael-ciniawsky removed this from the 1.2.8 milestone Aug 9, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants