Hi all,
I've been using SE v17 on Windows for about a year and while I like the editor and its potential, I have to say the UI lock-ups are driving me nuts. This is usually when I see it happen:
1. Switch away from SE and then switch back. Sometimes it takes 5-10 seconds to return control to me. As expected, Windows will mark it as "not responding" if I try to interact with it while it's in that state.
2. Sometimes the above happens while I'm interacting with SE, i.e. no switching back and forth needed. That happens less frequently though.
3. Auto-complete sometimes locks up the UI as well. It feels like it's doing a symbol look up in a gigantic database, which I don't think is the case.
The lock-ups happen frequently enough that it's reducing my productivity. Also, sometimes SE locks up for long periods of time, to the point that I have to kill it, which often means the databases will get corrupted (which causes SE to randomly crash).
The machine where SE is running on is plenty capable so no excuses there.
I use a tag file for my project and one for the compiler (basically including the Windows SDK):
Project tag file: 73K files, 530MB
Compiler tag file: 5K files, 201MB
I sure hope these are not considered too big. Is it?
In all cases where I could catch SI in the debugger there was a call (direct or indirect) from tagdb.dll into some wait function (e.g.: WaitForMultipleObjects) from the UI thread. Why is SE calling wait functions from the UI thread?
Any idea what I can do here to alleviate the problem while still keeping the value of using SE (i.e.: I would still want to use the tag database). I assume there won't be a definitive fix for this until the tagdb.dll calls are moved to a non-UI thread.
Thanks.