MySQL and IDEs (import)

I was reckless enough to try importing MySQL into kdevelop while compiling; the machine went to max load, then just froze. That's can't even ssh into the box for several minutes freeze. Fine, I'm not unreasonable. Next attempt: no load, just the import. Load 1, for several minutes. This time, the import succeeds (rather than die at 96 %), and the class-browser fills up. When I click on a declaration in the source however, I don't get the definition. So they parse all that info for the class-browser anyway, but they can't use that when I click on a declaration? What's up with that? So it relies on good old ctags for that. Fair enough, I suppose, why re-invent the wheel. Of course, the question that's on everybody's lips right now is, What was all the load I saw when they didn't even see fit to create ctags? Incidently, there's also a menu-item you can use to call up the usual find/grep combo to locate something within your project; this also saturates the CPU. They may be forcing a widget-update on each match, but even for that, it seems excessive. I'm flabbergasted.

anjuta, essentially "GDevelop", does not saturate the CPU, but it does take its sweet time at 778 seconds for the import. Yes, that's almost 13 minutes — on an otherwise idle Athlon XP2000+ in a 1GB machine. Again, tags are not part of the parcel.

Running etags from the command-line on the other hand returns within a second or two, and can be used within emacs pretty much instantly (some might also wish to M-x speedbar) — even while kdevelop's still hogging the CPU and both of kdevelop and anjuta are still loaded. I think I may have a winner.

Further investigation pending, I can only assume that the "GUI IDEs" spend their time creating a lot of info that I don't really find necessary to the way we dinosaurs work. Whether this is a real world consideration I'll leave up to the reader — how often do you actually run imports on projects of that size? It's just not a favourable first impression.