All the benefits of the last couple of years in faster build times have been annihilated. Now we see a 2x to 3x longer build, also on tests which is a big step back in developing.
If this isn’t fixed quickly we’ll roll back the update as this affects our productivity.
Also, why do we get this debugger statement in debug.ts all of a sudden? Do you guys realize there are developers that use a proper IDE and don’t need a mandatory debugger statement that stops the start every freaking time?
We don’t need TS support personally (we use proper check() mainly) but I understand it’s wanted to others. But man, this has really been a big step back for everyone in terms of build and test times and developing.
@a4xrbj1 We are affected by this as well although i think for us the problem increases trough #10806 as our project is relatively big. I guess that’s why we see a degradation of close to 300% where the report talks about 150%
Thank you for this information. It’s good to know it’s not something on our end. We have two (frontend and backend) large projects as well though it’s not a 3x increase that you see.
We did see a noticeable slowdown of build time. I would say, without measuring, that it takes at least twice as much time for Meteor to run in development. After it starts, the reload on file changes is as fast as it has always been, maybe even faster.
We just didn’t complain about it, because we have a pretty large project (almost 10K files) and I assume build times could get quite bad at this size.
I have found that setting the environment variable METEOR_DISABLE_OPTIMISTIC_CACHING=1 can help improve memory usage during meteor build , which seems to improve the total build times.
A number of replies in that thread say this has been helpful.
Thanks. We tried that first thing, but no, it didn’t change a thing in our case. We should do some profiling, but no time for that now. If it gets too bad, I’ll try and debug the cause.
| ProjectContext prepareProjectForBuild.......................331,917 ms (1)
| ├─ _initializeCatalog.......................................330,436 ms (1)
| │ └─ LocalCatalog#initialize...............................330,435 ms (1)
| │ └─ LocalCatalog#_loadLocalPackages....................330,427 ms (1)
| │ └─ PackageSource#initFromPackageDir................330,398 ms (15)
| │ └─ sqlite query 330,317 ms (13)
This was the result from the profiler (METEOR_PROFILE=100) when I added a space to a string in a file (inside a package) and hit save. Similar results in both 1.8.2 and 1.9b4 - Interestingly, even though one file in one package was minorly updated, every package reloaded, and took about 25-30 seconds each during the ProjectContext prepareProjectForBuild stage.
This app has about 10 packages of relatively small size.
Any idea why so much time is spent on a sqlite query?
I downgraded to 1.8.1, launched the app, then changed that one file again (removed the space), and when I saved it, got this:
| ProjectContext prepareProjectForBuild.........................1,234 ms (1)
| ├─ _initializeCatalog...........................................133 ms (1)
| │ └─ LocalCatalog#initialize...................................133 ms (1)
| │ ├─ addPatternsToList 41 ms (2)
| │ ├─ LocalCatalog#_computeEffectiveLocalPackages.............23 ms (1)
| │ │ ├─ files.readdir 2 ms (2)
| │ │ ├─ files.stat 6 ms (13)
| │ │ └─ other LocalCatalog#_computeEffectiveLocalPackages 16 ms
| │ └─ LocalCatalog#_loadLocalPackages.........................68 ms (1)
| │ ├─ PackageSource#initFromPackageDir.....................64 ms (15)
| │ │ ├─ files.stat 9 ms (15)
| │ │ ├─ runJavaScript package.js 3 ms (15)
| │ │ ├─ sqlite query 44 ms (13)
| │ │ └─ other PackageSource#initFromPackageDir 7 ms
| │ └─ other LocalCatalog#_loadLocalPackages 4 ms
Now the sqlite query is way down (I had to set METEOR_PROFILE down to 1ms to capture it). Does this shed any light on where the bottleneck might be?
I hope this gets proper attention. This kind of slowdown as part of updates should never go official.
I hope the message is well received and the problem will be tackled with appropriate priority (which is to say the highest)
