Fixes#10073, per
https://github.com/meteor/meteor/issues/10073#issuecomment-405290391
While thinking about this bug, I realized that sending IPC messages to
specific packages in the server process was much less flexible than
sending messages based on an arbitrary topic string, since the topic
string approach allows both `autoupdate` and `dynamic-import` to listen
for the same message.
The topic string approach calls for a listener interface like
`onMessage(topic, callback)`, which elegantly replaces the previous
approach of requiring packages to export a single `onMessage` function.
However, because the `meteor` package does not have access to the module
system, implementing the `onMessage` listener interface in the `meteor`
package would have required exposing an API like `Meteor.onMessage(topic,
callback)`, which has an unpleasant global smell to it. Instead, the
`onMessage` function should be explicitly imported (using the module
system) from a less-generically-named package.
Since I knew I was going to have to move the message dispatch logic out of
the `meteor` package, I decided to create a new package called
`inter-process-messaging` to implement the parent/child components of the
IPC system.
By my calculations, the sum of the sizes of the individual isopackets was
152MB, and the size of the combined isopacket is now just 36MB. That
remarkable difference goes to show how much duplication of transitive
dependencies was happening before this change.
That's a savings of 116MB for the (uncompressed) size of the meteor-tool
package. In Meteor 1.5.x, the meteor-tool package is about 544MB, but in
Meteor 1.6 it's considerably smaller: 373MB. In other words, this change
should reduce those sizes to 428MB (-21%) and 257MB (-31%), respectively.
Related to https://github.com/meteor/meteor/pull/8728#issue-232369984,
though these changes apply only to the meteor/tools codebase. We still
need to make similar changes to the babel-compiler package so that
application code will benefit.
The assumption that we're using Node 8 also allows some simplifications to
the runtime polyfills that we use.
Meteor 1.4.2 has been mostly focused on improving rebuild times, but what
ultimately matters is the time from changing a file to being able to make
requests against the restarted server, and any code that runs before
server startup should be considered part of that critical path.
If you have a lot of packages, and they do non-trivial work on startup,
this commit should give you much better insight into where time is spent.
Credit to @stubailo for pushing me to provide Meteor developers with
better profiling tools, and thanks to @veered for this specific idea.
Note: because tools/tool-env/profile.js is now loaded as-is by boot.js,
certain ECMAScript features are off-limits, e.g. ...rest params.
Now that the blaze submodule is mounted inside the packages/non-core/
directory, it appears that we no longer have to mention it explicitly in
the localPackageSearchDirs array.
We can revisit this conversion if it turns out anyone really wants to use
@import rules in CSS files instead of using something like LESS.
Part of #6037.
- We don't want to do a bunch of parsing *per comparison* when sorting
a list of package version strings. package-version-parser's `compare`
(and server's `compare`, which it uses) both accept either a string
or a parsed record. By parsing explicitly with memoization, we avoid
a super-linear blow-up in the amount of parsing. This'll save someone
half a second, at least.
- Adjust profiling hooks and messages
- Expose `Profile` to isopackets
Note that `export default` no longer modifies `module.exports`, but simply
defines `exports.default`, so these two import styles will work:
import DefaultExport from "./export-default-module.js"; // preferred
var DefaultExport = require("./export-default-module.js").default;
but this style will no longer work:
var DefaultExport = require("./export-default-module.js");
Previously, we would generate reports on
"Selecting Package Versions" and "Rebuild App".
- Instead of just profiling constraint solving, profile the entire
process of preparing the project via ProjectContext, by giving
each public function that "advances the stage" a Profile.run
(typically prepareProjectForBuild).
- Improve profiler output to better distinguish multiple runs
- Distinguish "Build App" and "Rebuild App"
- Instrument lots of calls that weren't instrumented before
Background: we omit entries from the report whose time is below
a threshold (by default 1ms).
This change prevents a display like the following, where the
presence of child entries creates a "group" but the group
appears to be empty except for "other":
```
foo...........30 ms
other foo 29 ms
```
METEOR_PROFILE=1 sets the threshold for displaying profiler entries
to 1ms. Previously, however, passing "0.1" or "0" would enable
profiling but use the default threshold of 100ms. With this change,
any recognizable number passed as METEOR_PROFILE will be used as
a threshold, including "0.1" and "0".
profile.js uses some "dumb" data structures and algorithms that are
N^2 or even N^3. If you experiment with adding more data to the
profile (e.g. names of files written), you'll find that the time it
takes to generate the profiler report blows up. This commit
makes the profiler usable again in that case.
* Don't create a new array in isChild(.), and compare elements
starting at the end (because early elements are more likely
to be similar)
* Swap order of entryName(.) (cheap) and isLeaf(.) (expensive)
in leafTotal(.)
Switching from "require" to "import" in the coffeescript plugin
broke our hack that keeps coffeescript from clobbering our version
of Error.prepareStackTrace, because imports are automatically
hoisted to the top of the file, and thus so are any side effects of
requiring a module.
The new fix has the tool save a copy of the correct
Error.prepareStackTrace so that any plugin that wants to unclobber
Error.prepareStackTrace can do so.
Other, fancier fixes are possible; there's a package called
stack-chain that installs a getter/setter on
Error.prepareStackTrace:
e51a7b2e0f/stack-chain.js (L136)
