There are small typos in:
- docs/source/commandline.md
- tools/isobuild/compiler-deprecated-compile-step.js
- tools/utils/buildmessage.js
Fixes:
- Should read `libraries` rather than `libaries`.
- Should read `file name` rather than `filenanme`.
- Should read `compatibility` rather than `compitability`.
Signed-off-by: Tim Gates <tim.gates@iress.com>
* rename
* we don't need underscore to check whether an array is empty
* add types, resolve type issues
* remove unused markTop in run.js
* Make the type a little more consistent
* Tweak a check for an empty array
Co-Authored-By: Marcelo T Prado <marceloterreiroprado@gmail.com>
Whenever you're looking at a stack trace generated by the command-line
tool, you see tons and tons of useless stack frames for withValue,
enterJob, and/or capture.
Each of these function calls has its own try-finally block, which is
probably the real reason this pattern is slow, though the excess of
unnecessary stack frames is subjectively gross as well.
Initial build times for the `meteor create --full` app on my machine are
about 4.4 seconds with Meteor 1.8, and just 2.8 seconds after this change,
which is a nice 36% improvement. Rebuild times are not noticeably
different, however.
Looking to the future, flattening this function call pyramid should make
it easier to introduce non-Fiber-based async/await into the buildmessage
system, so that we can start properly propagating promises up the stack.
Since markBoundary is essentially creating a bound wrapper function,
there's no reason we can't actually bind the function to a specific
context (this) object at the same time, instead of having to bind the
function and then wrap it with buildmessage.markBoundary.
