* 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>
I noticed recently that progress messages were no longer displayed (though
the ASCII spinner was still animating). I bisected the problem to the
progress.ts conversion in #10650, and I attempted to reproduce the
conversion, step by step. The problem ended up being the renaming of
._title to .title, which was a mistake because external code accesses
progress._title. Once I updated those invasive access points, progress
messages began displaying once again.
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.
This adds a memoized helper function for detecting Emacs throughout the
CLI tool and automatically resorts to "ProgressDisplayStatus" mode when
Emacs is enabled.
In my tests with both Emacs 22 and 27, this nearly doubled performance
when using Meteor from within the Emacs shell (i.e. `M-x shell`).
This means running `meteor update` on Windows with an existing (pre-1.6)
installation of Meteor will install a 32-bit version of Meteor 1.6, even
if the underlying machine architecture could handle a 64-bit version.
To get a native 64-bit version of Meteor, Windows developers should
reinstall Meteor 1.6 from scratch using the new and improved Windows
installer (👋 @abernix), rather than running `meteor update`.
If we really want to make `meteor update` just work ✨, we can
revisit this change in Meteor 1.6.1.
Since we can't change the springboarding logic of existing Meteor
releases, this decision has to be made by the springboarded-to Meteor 1.6
release, and may result in a second springboarding.
Once Windows developers update to a 64-bit version of Meteor 1.6, they may
still wish to run apps using older versions of Meteor where only 32-bit
builds of meteor-tool are available. This commit makes that possible.
This commit reverts much of the work @hwillson had put in place for
meteor/meteor#9173, which made it possible for 32-bit and 64-bit
Mongo versions to exist in harmony within the same dev-bundle. That
hard work was not in vein though as it offered invaluable research.
Ultimately, this showed that a more aggressive approach would be ideal,
even if the proposed option would have worked great in the short-term.
In the wake of the news that Mongo would no longer be supporting 32-bit
versions, these changes are important so 32-bit users of Meteor can
continue to have a functioning Mongo binary in development, while still
allowing Meteor to ship newer Mongo (e.g. 3.4+) binaries for 64-bit
users. This is particularly relevant for Windows users, who have
previously only had 32-bit Meteor builds and represented a majority of
"32-bit" development, despite the fact most of their hosts supported
64-bit. During another time in Meteor's life, this made sense.
This commit takes improved functionality to the next level (and makes
the aforementioned changes obsolete) by introducing support for building
and shipping Meteor for Windows in a 64-bit flavor (in addition to
32-bit), which will hopefully solve a number of performance matters on
Windows by using binaries which are pre-compiled for 64-bit, rather than
forcing the Windows kernel to deal with 32-bit binaries. While Windows
has shown it's quite capable of dealing with such a situation, it seems
more and more clear (given improvements in underlying dependencies) that
performance gains could be had by freeing Windows of its 32-bit work.
This commit also further perpetuates the "archinfo" plot-line with more
story (about Windows) and various spelling corrections.
These changes introduce dual Mongo support into the Meteor
Tool. 32-bit Mongo (3.2.15) will be used by Meteor when the
Tool is run on a 32-bit OS (32-bit Linux and Windows). 64-bit
Mongo (3.4.9) will be used when the Tool is run on a 64-bit
OS (64-bit Linux, Windows and macOS).
Fixes https://github.com/meteor/meteor-feature-requests/issues/129.
The pull request corresponding to our fork is not going to be merged, so
it's better to use the alternative this.finished API available in newer
versions of the upstream package.
https://github.com/williamkapke/node-eachline/pull/4
With Meteor 1.6 / Node 8, I noticed _buildLocalPackages taking multiple
seconds on initial server startup and restart, and the problem seems to be
that we call the global.gc function too often. This wasn't a problem in
previous versions of Node, as far as I know, but it makes sense to heed
the comment in tools/utils/gc.js, now that it matters.
