While you probably could tinker with the configuration, removing various plugins etc, it's likely to be more cost effective to buy more memory. How much do you currently have? I would consider a developer machine with less than 2GB of memory to be under spec, and I suspect many people would double that...
Modern versions of Eclipse do need quite a bit of RAM to do their thing. But should still run pretty fast on any modern machine.
Assuming you have enough physical memory (2GB is fine unless you have lots of other processes running, or you're using RAD), see this article on Eclipse's memory usage for some tips on tweaking the settings. The two most common culprits are Xmx and/or MaxPermSize being set too low (Xmx defaults to 256M and MaxPermSize defaults to 64M).
You modify the values by passing command line arguments or tweaking the eclipse.ini in the Eclipse install location.
You can switch off the plug-in by going to Window -> Preferences -> General -> Editors -> Text Editors -> Spelling, and unchecking the box title 'Enable spell checking'.
Of course, the tips offered to use larger heap sizes and better garbage collectors would do you good as well.
If 400 Mb of RAM is a big issue for you, you might want to try another IDE. Eclipse stores a lot of state information, some or most of which you don't actually need. That's a design choice.
Right now, I have the same project open in both Eclipse and QtCreator: after a clean rebuild, Eclipse uses 156 Mb RAM, Qt Creator is happy with 66 Mb.
My Eclipse is taking over 800MB resident, and 2GB virtual (part of it swapped out perhaps).
Java can be a hog, it's giving Java bad press all the time.
However, there is a little something that many people don't know: the incremental garbage collector. -Xincgc
The side effect is that it hands memory back to the system from time to time.
By default Java just takes and takes, and when it doesn't need memory anymore, it keeps it for itself.
The incgc is a different strategy where it becomes more reasonable to assume that memory can be handed back the system without running into trouble.
This can however affect performance.
There are many garbage collection settings. You can also have multiple threads handle GC. The parallel GC does that. Not sure if that one hands memory back, don't think so.
You can try the 64bit version of Eclipse with the 64bit version of JDK on Windows 7. Those both caused some odd issues with the 3rd party Framework I have to work with. The 32-bit of JRockit (free now) from Oracle seems to be faster and be a little better on memory. This is my Eclipse.ini settings:
I switched to the 32 bit JRockit JDK which seems a little faster for Eclipse. I turn off and don't install more than I need. For each separate type of app development (Android, J2EE, just Spring, ...) I have different Eclipse installations. Hard drive space is cheap. Then I can have just the plugins I need for each one. I would never want all the Android tools loading if I wasn't using them. STS is also good for just the Spring stuff and I have one just for OpenShift Cloud work.
Checking General -> Show heap status will enable this
in the bottom bar.
This way you can manually run the garbage collector whenever you want by clicking on the trash can. It's not a fix, more like a workaround, but it helped reduce massively my RAM / CPU usage.