-
Notifications
You must be signed in to change notification settings - Fork 12
Any ideas where this could slow down the build process? #29
Comments
👍 |
https://github.com/arunoda/hello-react-meteor/
Older version before upgrading from v 0.5.0 > 0.8.1
After upgrade to upgrading from v 0.5.0 > 0.8.1
|
I don't see cosmos:browserify mentioned in the first profiling to make a comparison. Version 0.8.1 uses the MultiFileCachingCompiler provided by Meteor's new build API and will have a speed increase when it considers the file unchanged (by its source hash, file options in package.js, and exports in package.js). Checking those, and writing to and reading from the cache, are handled by the new build api in 0.8.1. I git cloned the repo you referenced, ran it with the command you gave, and then tweaked a few files to cause it to rebuild a few times. It's a lot faster in later rebuilds because it avoids running browserify again by using the cached result. Also, you're browserifying a file for both the client and the server; which we discussed recently is possible. However, it looks like meteor is sending that file to the plugin twice, once for each scope. That's taking extra time on the initial build as well. I recommend not using browserify on the server side. I did notice Meteor sometimes runs the plugin when it should use the cached version. Sometimes only the client or only the server and sometimes both. That makes me question the new build api's reliability for detecting whether a file has changed or not. so:
|
thanks @elidoran When you say " It's a lot faster in later rebuilds" was it faster than the results I got using the profiling ? Hope you find something around this issue. |
The build time with this package is insane, removing it speeds up the rebuild time a lot. Please, do something with it. |
@sahanDissanayake Yes, by faster I meant faster than what you show. I should have included the profiler output, so, I'll add some profiler output below. To repeat what I did for yourself, start the app like you did, edit different files so it reruns the build. When the build system identifies the file to browserify doesn't need to be rebuilt it uses the cached result instead. It's basically very similar to what I was doing manually with version 0.5 except it's part of the Meteor build API now. When it avoids the unnecessary work it's fast and it looks like this: => Client modified -- refreshing|
| Select Package Versions: 1806.7
| Input#loadFromCatalog (sqlite): 1750.1
| other Select Package Versions: 54.7
|
| Input#loadFromCatalog (sqlite): 1750.1
| other Select Package Versions: 54.7
| Total: 1804.8
|
| files.rename: 177.5
| Rebuild App: 419.6
| bundler.bundle..makeClientTarget: 215.1
| Target#make: 215.1
| Target#_emitResources: 136.2
| PackageSourceBatch#getResources: 133.5
| PackageSourceBatch#_linkJS: 132.1
| other PackageSourceBatch#_linkJS: 80.5
| bundler..writeTargetToPath: 181.1
| ClientTarget#write: 180.4
| other ClientTarget#write: 168.3
|
| files.rename: 177.9
| other ClientTarget#write: 168.3
| other PackageSourceBatch#_linkJS: 80.5
| Total: 426.7
=> Client modified -- refreshing (x2) When it is being weird and rerunning the browserify plugin when the file hasn't changed it looks like this: => Client modified -- refreshing (x2)
| Selecting package versions /
| Select Package Versions: 1849.3
| Input#loadFromCatalog (sqlite): 1784.6
| other Select Package Versions: 62.7
|
| Input#loadFromCatalog (sqlite): 1784.6
| other Select Package Versions: 62.7
| Total: 1847.3
| Building the application |
| files.readFile: 128.4
| Rebuild App: 5646.3
| bundler.bundle..makeClientTarget: 339.7
| Target#make: 339.6
| Target#_emitResources: 135.5
| PackageSourceBatch#getResources: 133.1
| PackageSourceBatch#_linkJS: 131.7
| other PackageSourceBatch#_linkJS: 80.7
| ClientTarget#minifyCss: 123.5
| bundler.bundle..makeServerTarget: 4722.6
| Target#make: 4722.4
| Target#_runCompilerPlugins: 4536.3
| processing files with cosmos:browserify (for target os.osx.x86_64): 4498.7
| other processing files with cosmos:browserify (for target os.osx.x86_64): 4497.1
| Target#_emitResources: 166.7
| PackageSourceBatch#getResources: 163.0
| PackageSourceBatch#_linkJS: 161.3
| files.readFile: 57.2
| other PackageSourceBatch#_linkJS: 97.3
| bundler..writeSiteArchive: 557.5
| bundler..writeTargetToPath: 497.1
| ClientTarget#write: 184.5
| Builder#write: 52.4
| bundler..writeFile: 52.3
| Builder#write: 51.2
| other ClientTarget#write: 78.3
| ServerTarget#write: 309.8
| JsImage#write: 259.0
| Builder#write: 122.1
| other JsImage#write: 131.3
| Builder#complete: 55.4
| files.rm_recursive: 55.3
|
| other processing files with cosmos:browserify (for target os.osx.x86_64): 4497.1
| files.readFile: 235.9
| other PackageSourceBatch#_linkJS: 178.1
| other JsImage#write: 131.3
| ClientTarget#minifyCss: 123.5
| files.writeFile: 102.6
| other ClientTarget#write: 78.3
| files.rm_recursive: 56.3
| Total: 5403.2
I20151030-16:50:08.625(-4)? server...
=> Meteor server restarted I edited an app file and it reran the browserify plugin. That's not what the build API is supposed to do. Look here to see how the new build API decides whether to use the cached version or not. Also, the Meteor Build API for Compilers. And, the explanation of the caching compilers Meteor provides. |
I'm attaching some outputs of both the profile and some console.log() statements with the time it takes the plugin to run its functions. The files to browserify for the app you ref'd are When looking at the times it all comes down to the the Attachments: (BP means Browserify Plugin, BPT is a fn's time)
In 2-5 none of the files to browserify were changed, so, they shouldn't have be rerun through the plugin, but, they are. That's a waste of time caused by the cache not being used. Both 4 and 5 should have been the same because I changed the same file each time. However, the first time it rebuilt one file, the second time it rebuild two files. That's weird. So, the problem centers around Meteor's build API inexplicably calling the plugin when the result is actually cached. So, I looked at the So, why did that make things weird? Well, the react package is browserifying the file for both the client and the server. This way they only need to maintain a single file for both scopes. I understand that. It also means it's using browserify for a server side file, which isn't the usual thing. Most importantly, it exports two vars for both client and server scopes, and then exports a single var for only the server scope. That means So, it seems With that changed the rebuild outputs look like:
Note: the original build will still take time because Browserify is doing its thing to generate the result to cache. |
commit closed the issue, feel free to add comments or reopen. |
@elidoran Thanks very much for all the explanation and the time.. I get an average ~4s rebuild time now 💃 Keep up the good work |
I got a request saying new version of browserify slowdown the process.
See: kadirahq/meteor-react-layout#32 (comment)
Any ideas?
The text was updated successfully, but these errors were encountered: