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

module: ignore package.json/ directories #18261

Closed
wants to merge 4 commits into from
Closed

Conversation

bmeck
Copy link
Member

@bmeck bmeck commented Jan 19, 2018

Fixes: #8307

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

module

@nodejs-github-bot nodejs-github-bot added the module Issues and PRs related to the module subsystem. label Jan 19, 2018
@jdalton
Copy link
Member

jdalton commented Jan 19, 2018

Could this be handled at the C++ level of the InternalModuleReadFile/InternalReadModuleJSON methods instead? That way the guard isn't needed to be added to each potential use of the internal method.

@bmeck
Copy link
Member Author

bmeck commented Jan 19, 2018

@jdalton could, but then it won't be in the stat cache.

@jdalton
Copy link
Member

jdalton commented Jan 19, 2018

Is there a way to share a cache between C++ helpers and external...
kinda like the statValues typed array?

@bmeck
Copy link
Member Author

bmeck commented Jan 19, 2018

@jdalton the statValues approach has a known size, the stat cache is a growable Map. I don't think the same approach can be used.

@jdalton
Copy link
Member

jdalton commented Jan 19, 2018

Ah, okay.

@guybedford
Copy link
Contributor

If internalModuleReadJSON returned an empty string in this case, surely that would be cached as an empty main resulting in the same behaviour, whilst avoiding round-tripping latency?


try {
require(fixtures.path('module-package-json-directory'));
process.exit(1);
Copy link
Member

Choose a reason for hiding this comment

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

Would it be better to assert.fail here instead? I'm thinking from the point of view of how it might look in the CI if the test failed here.

Copy link
Member

Choose a reason for hiding this comment

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

Can't we just use assert.throws()?

Copy link
Member Author

Choose a reason for hiding this comment

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

it would just be caught by the catch below.

Copy link
Member

@TimothyGu TimothyGu left a comment

Choose a reason for hiding this comment

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

LGTM with @richardlau's comment fixed.

Copy link
Member

@bnoordhuis bnoordhuis left a comment

Choose a reason for hiding this comment

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

This shouldn't land as-is. A lot of time and effort has been spent on making this particular code path fast.

lib/module.js Outdated
@@ -123,6 +123,10 @@ function readPackage(requestPath) {
return entry;

const jsonPath = path.resolve(requestPath, 'package.json');
const rc = stat(jsonPath);
Copy link
Member

@bnoordhuis bnoordhuis Jan 20, 2018

Choose a reason for hiding this comment

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

Don't introduce extra system calls that are practically never necessary. Handle it inside InternalModuleReadJSON(), it's the CHECK_GE(numchars, 0) in that function.

edit: since it's easier to just write it than try and explain it: #18270

Copy link
Member Author

Choose a reason for hiding this comment

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

resolved

@bmeck
Copy link
Member Author

bmeck commented Jan 20, 2018

@bnoordhuis your requests have been upstreamed to this PR

@bmeck
Copy link
Member Author

bmeck commented Jan 20, 2018

@guybedford changed to use ""

@jdalton moved to InternalModuleReadJSON

targos
targos previously approved these changes Jan 20, 2018
@bmeck
Copy link
Member Author

bmeck commented Jan 20, 2018

there was a bug in how packageMainCache was checking for entries if it InternalModuleReadJSON returned an empty string since it only checked falsey values. This has been fixed but I'd like a rereview due to that change.

@bnoordhuis
Copy link
Member

@bmeck Taking my code and merging that as your own without attribution or even so much as a thank you... that's not a nice thing to do.

@bmeck
Copy link
Member Author

bmeck commented Jan 20, 2018

@bnoordhuis I'd agree but have similar thoughts on repeated interactions with you. I'll add your attribution, you didn't seem to have any attribution or care about my efforts on your PR either though.

bnoordhuis and others added 3 commits January 20, 2018 09:50
@bnoordhuis
Copy link
Member

you didn't seem to have any attribution [..] on your PR

That's because there's nothing to attribute, I didn't take code or ideas from this PR.

@bmeck
Copy link
Member Author

bmeck commented Jan 20, 2018

@bnoordhuis your statements reinforce my feelings being similar to yours at being upset at the other person.

@bmeck
Copy link
Member Author

bmeck commented Jan 27, 2018

moving conversation to @bnoordhuis 's PR after having problems with differences in internal consistency choices. it ended up expanding the decision making process and can be discussed there.

@bmeck bmeck closed this Jan 27, 2018
@jdalton
Copy link
Member

jdalton commented Jan 27, 2018

Moved to #18270.

@bmeck bmeck reopened this Jan 29, 2018
@bmeck
Copy link
Member Author

bmeck commented Jan 29, 2018

Reopened for comparative review from @nodejs/tsc .

@jasnell
Copy link
Member

jasnell commented Jan 29, 2018

Actual benchmark run so we're not just guessing about potential perf impact: https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/109/console

@jasnell
Copy link
Member

jasnell commented Jan 29, 2018

At least for the module-loader microbenchmarks, there is no appreciable impact ...

                                                                        confidence improvement accuracy (*)    (**)   (***)
 module/module-loader.js useCache="false" fullPath="false" thousands=50                -1.83 %       ±5.23%  ±6.96%  ±9.05%
 module/module-loader.js useCache="false" fullPath="true" thousands=50                  1.49 %       ±4.89%  ±6.51%  ±8.48%
 module/module-loader.js useCache="true" fullPath="false" thousands=50                  0.31 %      ±10.37% ±13.80% ±17.98%
 module/module-loader.js useCache="true" fullPath="true" thousands=50                   1.14 %      ±10.69% ±14.23% ±18.54%

Not sure how much (if at all, that benchmark exercises this code, however)

@bnoordhuis
Copy link
Member

FWIW, I benchmark using one of the loopback sample apps (loads ~5,000 files and did something like 250K stat calls at first, IIRC) but any biggish real-world application should do. Warming up the disk cache with a few trial runs is a good idea.

@jasnell
Copy link
Member

jasnell commented Jan 29, 2018

Ok, do you have any numbers from the loopback sample that show the changes in this PR being a problem?

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

LGTM

@targos targos dismissed their stale review February 6, 2018 08:13

outdated

@targos
Copy link
Member

targos commented Feb 6, 2018

I am not against this PR but I would prefer to have the cache changes in a separate one

@Trott
Copy link
Member

Trott commented Feb 8, 2018

Closed in favor of #18270. (If that's not the right thing to do, by all means, re-open!).

@Trott Trott closed this Feb 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
module Issues and PRs related to the module subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

module: node aborts when package.json is a directory