You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 29, 2021. It is now read-only.
A description of the problem you're trying to solve
Our builds were in the order of 13-17 minutes, this made it very difficult to release faster. We upgraded to meteor 1.6, that lowered the build time but it was still around 8-10 minutes.
We tried to profile the build to see what was going wrong and realised that profiling only covered ProjectContext prepareProjectForBuild step.
First we thought it was a bug, reported to the main repo. @hwillson was kind enough to point out that this feature may have never existed.
Why you think this is a problem
I manually wrapped the buildCommand's invocation to run the profiler and added a few profiling points where I felt they were missing.
This led us to find that tarballing and minification were the biggest offenders.
Two simple changes we made caused our build times to reach under 4 minutes.
Passing --directory flag and tarballing via linux command
Disabling minification with the --debug flag (for staging builds)
Without profiling, we'd be shooting in the dark and might hit the issue at random, but with profiling it was clear as day.
Suggested solution
I do not know what a solution would look like, but we changed build function to have Profile.run("build",()=>{return buildCommand(options)});
We then wrapped several steps inside the buildCommand function to be wrapped with the profiler.
The text was updated successfully, but these errors were encountered:
Continuing from meteor/meteor#9472
A description of the problem you're trying to solve
Our builds were in the order of 13-17 minutes, this made it very difficult to release faster. We upgraded to meteor 1.6, that lowered the build time but it was still around 8-10 minutes.
We tried to profile the build to see what was going wrong and realised that profiling only covered
ProjectContext prepareProjectForBuild
step.First we thought it was a bug, reported to the main repo. @hwillson was kind enough to point out that this feature may have never existed.
Why you think this is a problem
I manually wrapped the
buildCommand
's invocation to run the profiler and added a few profiling points where I felt they were missing.This led us to find that tarballing and minification were the biggest offenders.
Two simple changes we made caused our build times to reach under 4 minutes.
--directory
flag and tarballing via linux command--debug
flag (for staging builds)Without profiling, we'd be shooting in the dark and might hit the issue at random, but with profiling it was clear as day.
Suggested solution
I do not know what a solution would look like, but we changed
build
function to haveProfile.run("build",()=>{return buildCommand(options)});
We then wrapped several steps inside the
buildCommand
function to be wrapped with the profiler.The text was updated successfully, but these errors were encountered: