If the METEOR_PROFILE env variable is set to a number, it would be used
a filter bound for reporting.
Useful to eliminate the noise of small and fast functions.
Ex.: `env METEOR_PROFILE=100 ./meteor` will only print sections that
took more than 100ms to complete.
This helps especially for app files changes:
- usually a file is changed alone, the imports are not changed
- the changed imports do not affect individually prelinked files (thus "prelink")
- there is no point re-prelinking all files when one is changed
Saves 400ms on an internal benchmark for a mobile edu app
An optimization to avoid writing the same files over and over again.
Tested only on Mac OS X.
There is a potential problem with this approach on Windows, since the
way processes retain open files is different.
On Linux (and I assume, OS X, too), when a process has a file open, it
reads the file from a memory snapshot loaded by OS. The OS also would
increment the reference count for that file, so even if it is unlinked
from the FS, OS would still keep it available as long as the process
keeps it open.
When we want to replace a file under a running Meteor app process, we
first delete the old built file and then write a new file to the same
path. In my understanding, it would force the OS to assign a different
inode for the new file, so the old file and the new file will be
different. Then, we either restart the app process, or signal it to
reload its assets, so it reads the new files, releasing the older ones.
I need to verify this understanding with somebody who actually knows how
OS and FS work.
There are a few different times when we detect duplicate compiler
extensions.
(a) We detect them in Plugin.registerCompiler if a single
isopack itself registers duplicate extensions.
(b) When compiling a unibuild in compiler.compile, we check to see if a unibuild's
plugin-providing dependencies overlap.
(c) When preparing a unibuild for bundle-time source processing, we
check the same condition.
(Why do we need to re-check in (c)? If a unibuild was published and
passed (b) at publish time but is being bundled with different versions
of dependencies, it might fail (c).)
There were a few fixes here:
- In compiler.js (b), if we detected a duplicate extension, the code to get
the name of the conflict package was wrong and could throw.
- In compiler-plugin (c), we just weren't using buildmessage.
With just those fixes, we would actually see *both* kind of errors show
up if the error was in the app rather than a package, because
bundler.bundle didn't actually bail out on error after compiler.compile!
So we added that fix too, with a relatively conservative WatchSet.
"app/" in stack traces was an artifact of how we lay out files in the
built server, not how the source files are laid out, and isn't actually
as good as just using the source file name. Slava improved this on this
branch by just using the real file name. So the test (newly merged from
devel) needs to be improved to match.
While we're at it, let's test for filenames in a package.
Resolves these conflicts:
meteor
scripts/dev-bundle-server-package.js
scripts/dev-bundle-tool-package.js
tools/files.js
This requires building a new dev bundle, and moving the wrapCallSite
thing to source-map-retriever-stack.js.
