So I was using SlickEdit since the day I started at Google, and forever was plagued by occasional insane slowness. (The original post is here: http://1-800-magic.blogspot.com/2007/12/setting-up-slickedit-to-work-with-large.html).
The nasty part is it's not always reproducible - the PC I am editing stuff on runs XP, but the source itself resides on a Linux box, where it's shared over SMB, and apparently sometimes the network authentication server at Google goes to some legacy mode, which XP only uses after timing out on the newer one, which makes this particular type of SMB request that SlickEdit makes to the file system on the server intolerably slow.
I've traced some of its slowness to dynamic makefile menus, and disabled these. Today I think have solved the other really nasty problem - occasionally SE will enter the mode where on every opening paren following a function name it would freeze for 5-10-15 seconds, before the paren would even appear on the screen. It was driving me up the wall.
So I ran netmon and looked at what was happening. It turned out that it was opening large amount of really big files - and these files weren't even open in the editor, although I've had them open a few days ago.
I immediately suspected tagging, and disabled it, but it did not change anything. Then I started looking at the autocompletion logic (Tools->Options->File extensions setup->Autocomplete). Disabling autocomplete did not help, but the pane right next to it was called tagging.
Parameter information looked promising, so I disabled the entries under there, and - lo and behold! - it worked! I can now type function calls without 5-10 second interval.
After a quick binary search I narrowed the actual problem to the "Auto-list compatible parameters". I have no idea what this is used for, but disabling it made all the difference for me.
Less features == more useful editor.
I am wishing for a simple text mode editor that would run on Linux (so I could use it with putty), have efficient tagging, and have normal Windows-like (or at least configurable) key mappings and cut and paste concepts, i. e. != emacs. Oh, yes, and the debugger should be integrated.
Any one up for writing Turbo GCC?