Reaction: Application takes an extraordinary amount of time to build/rebuild on Windows

[zenweasel]

Expected behavior

Build/Rebuild time to be approximately the same as other platforms

Actual behavior

First build takes upwards of 5 or more minutes

Steps to reproduce the behavior

1. Be on Windows
2. reaction init && cd reaction && reaction
3. Wait forever

.

[spencern]

@zenweasel do you have any recommendation or ideas as to what should be done to resolve this issue? As it stands this issue is not very actionable.

[zenweasel]

Why isn't this actionable? It seems like we should be able to profile and build and see why it's taking so long and try to determine why this is only happening to us? Just as we were approaching the greater dev performance issues?

[spencern]

I think that profiling the builds and including those times on this issue would be the absolute minimum that could be done to make this issue actionable.

"It's slow on windows" without any measurements or comparisons to an equivalent startup or build time on another platform with similar resources is not a clear issue and I wouldn't consider it to be actionable.

Many developers don't even have access to a windows box, so even attempting to reproduce this issue and generate comparable build times would be a significant amount of work.

[dhonig]

If we remove the windows pre-condition, then is it actionable? We might learn some things that help everyone on all platforms?

[zenweasel]

@dhonig We do have a build issue overall, but Windows build time is probably 5-10X what it is on OSX and Linux. There is probably at least something in there that is Windows-specific.

[zenweasel]

@spencern so if we had build time then this ticket would be actionable? Beyond that what would you expect this ticket to include?

[spencern]

I think ideally the research is done before a ticket is put into the backlog. As this is _not_ a ticket specifically about researching and comparing build times on various platforms (and I don't think it should be), I'd expect that the ticket would, at the least, have build profiles that exemplify the differences between the two platforms, with a link to full profiling in a gist for the platforms that are being compared.

The ticket could include suggestions for a better way to do things to make it build faster on Windows, or posit specific code changes that may have contributed to builds on the Windows platform taking longer than on other platforms

@dhonig I don't think that removing the windows pre-condition helps much, at that point it's just a "this app takes too long to build" ticket, which is not very helpful for the developer trying to resolve the ticket.

As it is now, from this ticket, it's difficult to know if this is a windows problem, a problem building a specific lib on windows, a meteor/windows problem, an issue where the Windows machine has fewer resources than the comparison machine, or something else.

[zenweasel]

@spencern Makes sense. Will add more detail.

[spencern]

@zenweasel another thing I'm just now thinking of:
For comparison tickets like this where we're comparing across platforms, it would be valuable to know the high level specs of the different machines as well (e.g. i7 16GB is going to perform differently than i3, 4GB regardless of platform)

[zenweasel]

Using this batch file to time Windows

@echo off
@setlocal

set start=%time%

:: Runs your command
cmd /c %*

set end=%time%
set options="tokens=1-4 delims=:.,"
for /f %options% %%a in ("%start%") do set start_h=%%a&set /a start_m=100%%b %% 100&set /a start_s=100%%c %% 100&set /a start_ms=100%%d %% 100
for /f %options% %%a in ("%end%") do set end_h=%%a&set /a end_m=100%%b %% 100&set /a end_s=100%%c %% 100&set /a end_ms=100%%d %% 100

set /a hours=%end_h%-%start_h%
set /a mins=%end_m%-%start_m%
set /a secs=%end_s%-%start_s%
set /a ms=%end_ms%-%start_ms%
if %ms% lss 0 set /a secs = %secs% - 1 & set /a ms = 100%ms%
if %secs% lss 0 set /a mins = %mins% - 1 & set /a secs = 60%secs%
if %mins% lss 0 set /a hours = %hours% - 1 & set /a mins = 60%mins%
if %hours% lss 0 set /a hours = 24%hours%
if 1%ms% lss 100 set ms=0%ms%

:: Mission accomplished
set /a totalsecs = %hours%*3600 + %mins%*60 + %secs%
echo command took %hours%:%mins%:%secs%.%ms% (%totalsecs%.%ms%s total)

Time on an i7/8GB and a non-SSD, running reaction test
command took 0:10:45.28

On Mac OSX 2017 2.7 GHz Intel Core i7, 16GB Ram, non-SSD
using time utility to test reaction test

real    3m47.370s
user    3m11.787s
sys 0m26.020s

Both projects are from a fresh clone

[zenweasel]

Comparing a blank Meteor project created with meteor create, running command meteor build $HOME/.

OSX:

real    0m28.203s
user    0m25.347s
sys 0m6.772s

Windows:

C:\Users\Brent\reaction_projects\blank_meteor>timecmd.bat meteor build ../output
command took 0:2:54.47 (174.47s total)

[zenweasel]

From the above numbers you can see that Reaction rebuild is roughly proportional. Rebuilding the default project takes 30 seconds and a Windows rebuilt takes about 3 minutes (roughly 3-6X).

There is this long standing (closed) issue on the Meteor project: https://github.com/meteor/meteor/issues/5091
One solution that keeps getting pointed out is switching to the Linux subsystem for Windows. I think that either this or Docker is probably where we need to go as I wouldn't expect that MDG is going to make any progress on this four-year-old issue.

There is also this open issue for supporting the Linux subsystem on Windows: https://github.com/meteor/meteor-feature-requests/issues/154

[zenweasel]

I would like to get Vishal's numbers from another Windows box if possible. @vwadher

[vwadher]

@zenweasel - Unfortunately I don't have another windows machine to leverage for this. Lets spin one up on AWS?

[zenweasel]

@vwadher Is there a reason you can't use your main one? I just wanted to get a "best case" number for reference and AWS is probably going to be behind running an actual desktop machine

[vwadher]

@zenweasel yup I can absolutely use my main one. I thought you said you'd like to have "another" windows box of mine since we already saw what happened on my main box. But anyway, yes of course I can use my main box. Let's connect on slack so you can run me through what is needed.

[zenweasel]

@vwadher Sorry, just meant another besides mine

[vwadher]

Here are the results -

command took 0:4:26.01 (266.01s total)

[zenweasel]

So the time on your machine @vwadher was almost the same amount of time it took on my OSX box. 🤔

[zenweasel]

It would appear that this is Meteor error that we can't really do anything about. The most hopeful path seems to be the Linux Subsystem for Windows which appears to be near completion.

Another possible solution would be to create a new version of the Docker image that points to a local drive but allows you to build/run the application within the container. Would certainly love to see a community contribution of something like that.

For people who want to just run just for evaluation, running Docker is a great alternative

Since there's really nothing we can do about this issue for now I am closing. I will add something to the docs.