Performance of the new builder

[Vincent Jaubert]

Hi everyone,

since a few releases, there has been a new builder (?) introduced in Meteor.
This new builder/changes watcher, use two node processes during development.
I'm developing on linux on a relatively old (3 years) laptop.
Before this change, rebuilde/.hot code push was somewhat slow, but bearable.
For me this is not the case anymore.
During building, one of the processes disappear, and the other take more than 100% (according to top) of one core.
The laptop then becomes sluggish, and it can take more than one minute between saving of a one line of code modification and the full reloading of the site. During this one minute, i go wandering on Facebook, and then i'm not very productive...
My app is relatively big, but for me it was working much better with the old "one process" builder.

[Daniel Dornhardt - Daniel Dornhardt Development]

My experience as well, it gotten a lot slower, and it takes a notable amount of time sometimes for my small to medium sized project to refresh on a relatively fast 3 year old macbook with more than enough RAM and an SSD drive.

Best wishes

Daniel

Daniel Dornhardt, Daniel Dornhardt Development

dan...@dornhardt.com

+49 152 - 56 17 22 61

--
You received this message because you are subscribed to the Google Groups "meteor-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core...@googlegroups.com.
To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.
For more options, visit https://groups.google.com/d/optout.

[David Collier]

hi -

thanks for the link, a few people have commented that 0.9 series made the build take 10x as long. it's crossed the line where meteor is now a drag to change anything, and no fun to work on.

for core - is there anyway to debug what's going on with the builder? like a more verbose mode?

I've taken the approach of developing everything in packages, ie nothing in the app/ itself. but even running with my essential /core/ packages, my app is taking forever to build.

I have taken pains to move any unused packages out of any meteor $PACKAGE_DIRS, so they aren't being parsed.

so i'm wondering if using multiple packages introduces a huge amount of overhead compared to just mashing everything into one big app? But it's a huge refactor to change that, so i'd like to know in advance if it will help (doesn't seem like it based on this thread).

additionally i heard at least around 0.8x there was some type of intelligence that if a package contents wasn't changed it wouldn't be re-built. was that removed in 0.9+ ?

could it be that using jade+coffeescript introduces a lot of compile/buidl overhead each time source is touched? or maybe stylus is slower than .less? 

Some insight into wtf is so slow would help. Is there anyway to profile the bundle/build process and see what's taking all the time?

tx

[Nick Martin]

Heyo,

Yeah, build speed has definitely gotten slow. There are a number of changes in 1.0-rc that may help speed things up for people. Can you please give it a try with `--release 1.0-rc.2` and see if it is any faster for you?

There is some verbose debug printing that might help pin down what is slow, though not too much of the build code has been instrumented yet, it's more the package catalog code and the mobile build code. You can try it with `METEOR_LOG=debug meteor --release 1.0-rc.2 run`.

Cheers,

-- Nick

[David Greenspan]

If anyone has a really slow app that they can share publicly (via repo), I'll take a look this week.  As Nick says, we're improving speed and also adding progress bars, so try with the latest RC.

-- David

[David Collier]

With 1.0-rc2 it's still running very slow for me.

@greenspan > i can share a repo privately if that works.

I tried with the METEOR_LOG=debug but that doesn't seem to give so much info.

So I looked into the /tools and added some logs to 

unibuild

compiler

builder

It looks like the code is parsed 3X?

I see a lot of this:

-- Unibuild standard-app-packages

-- Unibuild standard-app-packages

-- Unibuild standard-app-packages

-- Unibuild coffeescript

-- Unibuild coffeescript

-- Unibuild coffeescript

-- Unibuild stylus

-- Unibuild stylus

-- Unibuild stylus

THen whenever a package is used by another it will get unibuilt again it seems

-- lessons.on_use

-- Unibuild dcsan:lessons

-- Unibuild dcsan:lessons

-- Unibuild dcsan:lessons

-- Unibuild dcsan:landing

-- Unibuild dcsan:landing

-- Unibuild dcsan:landing

-- Unibuild dcsan:landing

-- Unibuild dcsan:landing

-- Unibuild dcsan:landing

-- Unibuild dcsan:datapack

-- Unibuild dcsan:datapack

-- Unibuild dcsan:datapack

-- datapack.on_use

-- Unibuild dcsan:datapack

-- Unibuild dcsan:datapack

-- Unibuild dcsan:datapack

-- Unibuild dcsan:bot

-- Unibuild dcsan:bot

-- Unibuild dcsan:bot

etc.

then three platforms:

addUnibuild os

addUnibuild web.browser

addUnibuild web.cordova

btw i'm not doing a mobile build, and have removed the cordova platform, but still get this.

and near the end

-- Unibuild npm-container

-- Unibuild npm-container

-- Unibuild npm-container

-- Unibuild npm-container

-- Unibuild npm-container

-- Unibuild npm-container

after the npm container and the first startup line of my own app... takes a few seconds.

I noticed addFile also adds all the static asset files

sourceItems [ { relPath: 'client/lib/custom.bootstrap.import.less' },

  { relPath: 'client/lib/custom.bootstrap.json' },

...  { relPath: 'public/placer/200x200.gif',

    fileOptions: { isAsset: true } },

but this doesn't take too long.

So overall i haven't found one big timesink, just lots of small processes. Is this build process instrumented somehow? 

/dc

[Vincent Jaubert]

Ok, rc7 seems to be more verbose during rebuild.
It seems the build process is waiting some long seconds (10-15 actually) on "downloading packages" on each code modification although the packages were not modified.
Is this normal ?

 

[David Collier]

rc7 seems maybe 2X faster than rc2, but still I think a lot slower than 0.8 series. but a great improvement!

I see a lot of "downloading packages" while it recompiles and sometimes a "cannot connect connect to package server"

i'm wondering if there's a way to turn this off if it is really doing network requests during the compile...

/dc

[Ekaterina Kuznetsova]

You could try to set the environment variabls

METEOR_OFFLINE_CATALOG=true

I don't know if that is going to help, since it should be contacting the internet a lot less now than it used to be -- but if you are on a slow network where updating the local cache (for example) is causing problems, that might help!

[Vincent Jaubert]

Ekate, the question is: is it normal that it's trying to update/figuring out the packages everytime you modify a line in your program althought nothing on the package side has been modified ?

[David Collier]

On Sat, Oct 25, 2014 at 1:08 AM, Vincent Jaubert <vjau...@gmail.com> wrote:

Ekate, the question is: is it normal that it's trying to update/figuring out the packages everytime you modify a line in your program althought nothing on the package side has been modified ?

in my case I am working on packages that are included in the app. so this could be triggering the  update?

but i'm not touching anything that would chnage dependencies, just package code. but that's hard for meteor to know without checking. hence some env flag to force that no-check.

/dc

 

Le samedi 25 octobre 2014 06:35:47 UTC+2, Ekaterina Kuznetsova a écrit :

You could try to set the environment variabls

METEOR_OFFLINE_CATALOG=true

I don't know if that is going to help, since it should be contacting the internet a lot less now than it used to be -- but if you are on a slow network where updating the local cache (for example) is causing problems, that might help!

--
You received this message because you are subscribed to a topic in the Google Groups "meteor-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-core/OyF0kxecxuw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meteor-core...@googlegroups.com.

To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.
For more options, visit https://groups.google.com/d/optout.

--
-----------------------------------------------
David 'DC' Collier
  d...@biz.pikkle.com
  skype: d3ntaku
  http://jp.linkedin.com/in/dcsan/
-----------------------------------------------

[David Greenspan]

+1 to Vincent's question.  I would like to know too.  From what I've heard from other core devs, there may not be a fundamental reason we do this (namely update/figure out package versions and seemingly go over the network on every file change), but there is some implementation complexity in fixing it so that the work will have to wait until the version after 1.0.

-- David

On Sat, Oct 25, 2014 at 1:08 AM, Vincent Jaubert <vjau...@gmail.com> wrote:

[Ekaterina Kuznetsova]

>> Ekate, the question is: is it normal that it's trying to update/figuring out the packages everytime you modify a line in your program althought nothing on the package side has been modified ?

It is currently normal to re-read the package.js files (but that shouldn't cause that much of a slowdown). It shouldn't be normal to have to rebuild a package (but sometimes it may look as though the package is being rebuilt, when it is not, depending on where you put a print statement -- though also, quite likely, there are some low-hanging post-1.0 fruit in there. It is sort of normal to rerun the constraint solver, but the second run should be pretty fast (it is just checking that the previous solution is still valid). We run the constraint solver in that mode a lot, and maybe in the post-1.0 future, we will eliminate some of those runs. Is it normal to talk to the network? That shouldn't be normal in 1.0-rc land, but was happening a lot in 0.9.x land, for stupid reasons.

We could probably be more efficient about reloading some of this stuff, but the first thing that we are going to do is figure out what is causing the slow-down, and then eliminate those problems, since they might be hiding some harder bugs. Rumor says that's at the top of the list for several engineers here post-1.0.

[Vincent Jaubert]

Le lundi 27 octobre 2014 20:24:40 UTC+1, Ekaterina Kuznetsova a écrit :

Is it normal to talk to the network? That shouldn't be normal in 1.0-rc land, but was happening a lot in 0.9.x land, for stupid reasons.

However, with 1.0-rc.9, i get a "downloading packages" on every server code change (not in a package)

I get "selecting package version" then "building application", then "downloading packages" (longest step of the three, more than 10 seconds), then again "building application".

[David Collier]

one other point is that it seems mongod is getting restarted a few times on a JS code refresh. I only think this since i see the process name changing in the mac terminal bar from node > mongo > node... , not a particularly scientific process watch but...

[David Collier]

>  "downloading packages" (longest step of the three, more than 10 seconds), ...

I'm getting this too now. It looks just like the meteor package server is under strain, as it wasn't like this last night at 4am. Oh wait - does that mean daytime west coast is a bad time to work on meteor stuff in the 1.0 build up? more AWS boxen pleeze!

/dc

[David Glasser]

Hmm.  mongod isn't supposed to be restarted at all here, unless it crashes.  Will be looking at this post-1.0 as part of a performance pass (see my other thread).

It sounds like we might be printing "downloading packages" when things other than downloading packages is happening.  BTW we serve packages through the AWS Cloudfront CDN.

[David Collier]

congrats on 1.0 :)

the slowdown seems back with a vengeance this evening. maybe cos of meteor's servers getting hit for 1.0 finally... (if the build process really is network dependent)

not sure where this issue is being tracked now, so added some more info to a closed ticket.

https://github.com/meteor/meteor/issues/2855

/dc

[Vincent Jaubert]

David C, there is more info there : https://groups.google.com/forum/#!topic/meteor-core/lsK9B8n_lLg

[David Collier]

hi -

did anyone find other workarounds to speed up the development cycle?

hopefully there's a new drop of the build tool soon, i did see some commits related to isopacks, but MDG seem to be chilling on the 1.0 after the breakneck runup...