I just tried a a clean+build on MPLABX 4.05 and XC32 on a project that generates 100K of code takes 9 secs...
A make with a change to one source file takes under 2 seconds
You don't understand, it's not the speed of compilation that's the issue, but the time it take for MPlabX to get the point of being
able to compile some code. Kiel Microvision takes 12 seconds to get up and running, Atmel Studio 4 takes 13 seconds, Embitz 20 seconds, MikroC Pro 21 seconds, MPlab 8.92 40 seconds (slow, but still acceptable). And once these IDEs get going they are relatively clean and responsive, unlike MPlabX which continues to do 'background' stuff that just gets in the way.
Unfortunately if you want to program the latest PICs there is no practical alternative to MPlabX, because it hides the chip configuration inside its database and trying to generate it by hand is just too painful. However once it has created a project with the required make file etc., you can compile from a batch file and use your favorite text editor to work on the source. Gets rid of the bloat, but is not quite as convenient as a proper IDE.
I like having a GUI with buttons to click on etc. rather than having to type in commands, but only when the response is immediate so it feels like I am in control. We have computers which are so powerful they should be able to do most stuff
instantly, not be hobbled by bloatware.
...on my X220, introduced 5 years ago, which can be had on ebay for £200 or less, with an SSD
That 'under £200' computer might cost me over NZ$700 once freight and customs duty was paid, then I would have to spend time setting it up. And it probably won't run Xp so I would have to get used to using an OS that I don't like. Why should I invest that kind of time and money (which I can't afford right now) just to program a $1.50 chip?
Sure I have an 'ancient' computer with a mechanical hard drive that could do with a defrag, but its lower performance just makes the issue more apparent. I have another more powerful machine running Linux which is assigned to another job. MPlabX is faster on it, but still has unexpected lags and still uses over 0.5GB of RAM. The fact remains that Java based IDEs are sluggish and MPlabX is bloated. That such bloat can be masked by throwing more hardware at it is irrelevant.