The price for the long build, compilation is not just wasted time, but also a broken thought process, disrupted work flow, higher chance of being affected by distractions, less enjoyment.
I put the build output directory for my project on a RAM disk.
My Build Times With and Without Using RAM disk|
| Without RAM disk | With RAM disk | Speedup |
|---|
| Full Build | 8 minutes 40 seconds | 6 minutes 40 seconds | 25% |
|---|
| "clean" Target | 1 minute 35 seconds | 5 seconds | 19 times |
|---|
Not bad. The build of this project includes Java compilation, generation of web services code, creation jar files, documentation, etc.
This setup was created for a Java project on Linux. The first thing the build process does is to call the command
ln -s /mnt/tmp build
On Windows you'll probably have to redefine the output directory, e.g. passing -Dbuild=F:\ to the Ant script. The clean-up target runs the command
rm -rf build/*
The RAM disk definition in my /etc/fstab file:
none /mnt/tmp tmpfs rw,exec,auto,noatime,uid=<user>,gid=<group>,size=512M 0 0
Replace the "<user>" and "<group>" with your Unix user and group names correspondingly. The nice thing about the Linux tmpfs system is that it takes only memory it actually uses. You can share the same memory disk between a few projects, if you work on one project at a time. To prevent the build process taking all the CPU, you can reduce its priority. With the Ant Java build tool, for example, this can be done with the option "-nice".
To make things even faster one could put whole projects on a RAM disk. On today's powerful development workstations with a few gigabytes of memory, many projects will comfortably fit into RAM. If there is not enough memory for the whole project, one can use RAM disk only for the most frequently used parts of the source tree. With this approach better CPU, additional memory, switching to a 64-bit operating system give much bigger payoff.
The downside of using a memory disk is that all the disk content disappears when the computer shuts down. This is not critical for the build directory or other generated data. One just reruns the build to create these files again. The risk is much bigger when placing a whole source tree on a RAM disk. To prevent data loss one could use rsync or a similar tool to continuously mirror the project directory to a disk or even to a network location. After a reboot one would copy the source tree from the mirror back onto the RAM disk.
The other ways to make your build process faster - make your build script better track dependencies, run only the part of the build required for the particular usage, break the project into a few subprojects, run a few parts of the build in parallel. Take a look at the guide by Jonathan Rasmusson.
A couple more observations - compilation and build is about one-third faster on Linux than on Windows. Turning on antivirus on Windows makes builds 40% longer! Build running in VMWare Windows virtual machine running on Linux host takes significantly less time than running it natively on Windows! Others saw similar results. All the measurements were done on the same hardware.
I'd like to hear from others about their experience with similar setups.
Now you can tell MouseFeed to enforce keyboard shortcuts instead of just reminding them. With this setting MouseFeed prevents an action invoked with a mouse click from running if it has the associated keyboard shorcut.
Another big improvement is the ability to customize handling of action invocations on a per-action basis. Just call the action you want to configure, let's say "Refresh", click on menu item "Last Action Invocation", and MouseFeed allows you to specify how this action invocation should be handled.
You can view all the action-specific settings in the MouseFeed preferences
