You could also do a quick audit of your file structure - check for files which are in the wrong place. One symptom of that is editing a client file which causes the server to reload (or vice versa).
Have you run meteor with profiling? For example:
METEOR_PROFILE=1000 meteor --settings xxx
will log steps taking longer than 1000ms (1s) to complete (you can adjust the value to suit). I’ve seen cases where a large js file has been accidentally included in the build and that command has highlighted it.
However, your project may just be very complex (lots of local packages, npm modules and build files). In which case, new hardware may be the only way to go.
The thing is (and I think it is one of the main reason) my current project use (unfortunately) Meteor 126.96.36.199, with almost 1500 files (for example a SCSS file with ~9000 lines… ). It is planned to improve all of this (structure and Meteor version), but that’s not the priority for some person here)
Concerning this SCSS file, for example, when it is changed only the client is refreshed (logged in the Terminal).
But the delay for detecting a change in this file, or any another “client file” take something like 30 seconds.
When a server file is modified, the change is detected more quickly, something like ~2 seconds. And I currently use this “trick” for whatever change I make in a file.