So, I'm working on a Mac Mini, using WebStorm to fuss with Meteor apps. I'm finding that WebStorm tends to get sluggish, and is constantly trying to index things. I have 4 gigs of RAM, of which 791M seem to be allocated to WebStorm at any one time. My disk drive is 500GB, and I make sure there's always at least 20% to 30% free space.
So, a few questions... is it Meteor's bundle process that's causing WebStorm to do the indexing? Is there any way to optimize the indexing? Make it run less frequently? Ignore the .meteor directory, perhaps? Is 20% of available RAM an appropriate amount to allocate to WebStorm for Meteor development? Are there any other things that people can recommend to optimize WebStorm so it's not so sluggish?
Thanks in advance for any recommendations!
As #Martin said - exclude the directories where Meteor stores it compiled files: .meteor\local and .meteor\meteorite (when using meteorite).
To have Meteor suggestions / ... add the Meteor source as an external library: /usr/lib/meteor/packages/. I'm using PhpStorm as well and add the path to the PHP include path (doesn't matter it's not a PHP-library).
When adding it as a JavaScript Library in the project settings the directory structure gets lost and you have to repeat this when upgrading meteor.
I'm using PHPStoem for my meteor development and I am having the same issue as you do. I guess the engine in PHPStorm is identical to WebStorm...
I'm unsure if increasing the amount of RAM available to the IDE actually will have any effect. The issue is related to the IDE re-indexing the folder-tree whenever changes are made to any file(s) in the tree.
When meteor is running and changes is made to a file, meteor is bundling the whole application into the .meteor folder why the tree is re-indexed.
I haven't tried it out yet, but I guess what actually will help is to add the .meteor-folder to the ignore list so it wont be re-indexed every time a file-change happens.
Related
My Next JS dev build has a 1.7Gb file named "core" in my dev directory. Ive been using next for a few months and its the first time i noticed it.
I cant find any documentation on its use or reason for it's existence and an increasing amount of projects its consuming a lot of hard drive space.
I have effectively deleted it (renaming it just in case I do need it) and my dev server is still running fine. Leads to the question what is it and why do I need it? Is it dev specific? I certainly didnt put it there myself and if Next needs it why is my dev server still running without it?
Any insights much appreciated.
Thanks
I am new to Meteor. I just start using Meteor for the first time. It seems a bit slow. I am developing on a Macbook Pro with SSD. I am using Firefox, and Vim. I tend to save the files frequently, causing it to refresh the browser. It takes a few seconds for the browser to refresh. I do not have much code yet. Are you experiencing this slowness? How can this be improved? Does MDG have any plan to improve this? If I make change to a file, can we cause the browser to just reload that file rather than doing a full build and causing the browser to reload all the files? Am I missing something? Thank you!
Unfortunately, you can't do anything about it. However, the complete rebuild takes place only when you change the server side code. For any client changes, the change is almost instantaneous.
You can try some workarounds by removing some packages from meteor but they will affect debugging.
There is a great thread on this issue on Meteor's Github Issue section. You can find it here
Also, you may consider using WebStorm as it is the only IDE with built-in meteor support. May help you speed up your dev time.
UPDATE: You may try using import functionality in Meteor 1.4 to define file dependencies. Also, have a look at this package
My Meteor file change watcher is taking forever to detect my file changes and refresh the browser, sometimes even longer than a minute. This makes developing a real pain.
My Meteor is running inside an Ubuntu-VM. The projects folder lies in my OSX and is mounted inside the VM. So I'm aware that inotify/kqueue won't work, so Meteor should fallback to stat polling.
I even set the environment variables according to this post, but the behavior is still the same.
METEOR_WATCH_FORCE_POLLING=true
METEOR_WATCH_POLLING_INTERVAL_MS=500
Is there any way to fix this annoying behavior?
The folder from OSX is mounted as a nfs share btw.
Update:
I did some testing and there is no difference if the application has a big amount of packages or is taking long to build, even with the very basic app you get after meteor create I still get the same behavior.
If I change a file in the VM (so that inotify works) the refresh is happening instantly.
I've have apps in production that incrementally become slower when adding packages, both 3rd party and private packages. I also discovered that adding 3rd libs directly on the client/lib increases the reloading time.
I'm not sure if Meteor 1.0.2 actually solved the problem of watching the directory efficiently.
What version of Meteor are you using?
Much of this lag-reloading issue was addressed on Meteor 1.0.2. While it still takes some time, I would say was ~5x faster on my experience.
I've recently started working on Grunt and figured out how to use its built-in live reload feature. I am using a WordPress theme to develop and asked the developers if they could better include the Grunt live reload functionality into the theme. They would insist on using the application instead (which isn't grunt). They said it would be dangerous to use as you should remember to remove the file from the production environment when you're done, even though I recommended a simple way to make sure it only stays in the development environment (which went ignored). I'm just curious as to what's the big disadvantage in using the grunt live reload vs the application? To me it seems better to keep it all with Grunt (by adding a couple of extra lines of code) instead of adding another tool to my workflow, granted it may be more dedicated to live reloading.
I work with grunt-contrib-watch with the livereload in almost every project and I didn't see any disantages so far.
The only problem that I can point out, is that livereload should be used only for lighter tasks or it can be a bit annoying if you're making him track heavy tasks.
It seems to me that your coworkers are being a skeptical for no reason, if you're not using grunt or gulp, putting them on your projects might be a huge improvement.
I checked out 86a52e6 on the master branch from the Meteor repo. Ran ./scripts/generate-dev-bundle.sh per the Slow Start (for developers) instructions. This goes off to work for awhile, generating a ton of output but ending with errors. All of them seem to be unused private fields in third-party libraries.
Has anyone seen anything like this? Any guidance would be most welcome! I've been getting to know my way around Meteor via the pre-compiled binaries, but this was my first attempt to build from scratch.
Running OSX 10.8.5.
Thanks in advance!
You don't need to compile your own dev_bundle. On first time you run meteor from the checkout, it will download compiled binaries (mongod, mongo, node and npm) for your system architecture.
Don't bother yourself compiling, just use ready binaries.