The fundamental problem with Visual Studio (C++) 2008
The find dialog is dog slow !!!
After some usage, "Find" or "Find In Files" becomes very slow. I tried leaving the find box docked in the IDE window, but every time I type CTRL+F the dialog box goes into some sort of refresh seizure and only comes back after 3-4 seconds (on a 4 cores machine with 3GB of RAM 8).. an eternity if you are trying to jump somewhere in the code.
I noticed the same problem on a colleague's machine. I tried installing the SP1 beta for VS2008, which supposedly fixes some slowness in the GUI, but it didn't fix that one for sure.
An alternative is using CTRL+D (which I never really used before) to go to a quick find box, however that doesn't allow to change parameters such as case sensitivity and search for whole words, nor to verify what the current setting is.
Visual Studio has really become a piece of crap. It's still my favorite IDE ...if coupled with Visual Assist X. But if you program in C/C++, then you are a second class citizen, as Visual Studio has really sold its soul to the web/NET/database development or whatever else usage do most bored programmers out there.
One example is the dialog for changing syntax coloring. There is no more "C++ comment code". That is hidden behind "XML Comment" or something similar along those lines !
Another very sad thing, which has been worsening with years since Visual C++ 6, is the context help.
Theoretically one could press F1 on a keyword or API call and get the context help on it. In practice one presses F1, waits several seconds for some large application to load (or even to access the net !) and then gets a completely unrelated doc.. if lucky (one could set some sort of filters, but those never work right somehow).
For Windows API calls I used to get the Windows CE docs a few versions ago. Now I just get garbage.
Works much better by going on the MSDN web site and do a web search there.
How can possibly Microsoft win the web search engine battle if it can't even put together a system to help find a few thousands API calls ?
One last rant, if I'm allowed (I think I am !): headers have become completely unreadable. Microsoft includes and STL stuff are so complicated that give practically no help.
They must be machine generated.. would be nice to see the source of those.
MS includes have all sort of odd decoration to specify whether parameters are in input or output or what kind of passing they use.. turning those headers into something that could win an Obfuscated C Code Contest (for ugliness).
Thaaaaaaaannnkksss !!!
Same with Delphi
I have a similar issue with the last few versions of Borland Delphi (now v 2007). Back in the good old days I could press F1 on a keyword and the help file would come up right away. Nowadays I try to avoid that as much as possible: pressing F1 freezes the IDE for 5-6 seconds (AMD X2 6000+ 3ghz, 8 GB RAM) then, if lucky, brings you to the right page that contains the api call explanation. If you try a search you must first select what language you are looking for (or multiple) between C#/C++/Delphi+C++/J#/JScript/Visual Basic, then after a few seconds you are given a bunch of results mixed from the local help file, msdn online, codezone communities, questions.. man what the fuck..
Now, if lucky, the documentation will 1) be up to date 2) correspond to Delphi wrappers. I've found more than once documentation for an api call which should return a 0 or something else, but in fact Delphi expects a Boolean type and when the error comes up you are only told there's a value mismatch.
Code search: ctrl+shift+F can search in all the project files, which is really helpful, but after a few uses an IDE error comes up and until you restart it you can't use this anymore..
This and many other bugs have been there for ages without a fix. memo/edit/richedit controls have been bugged as well for ages, as right-click doesn't bring the context menu anymore and you need to apply some 3rd party patch from someone kind enough who fixed that. Add that to the lack of Unicode (promised for this year), 64-bit compilation, ...
Maybe it's time to switch over to VS.
ps: math captcha still there after being logged in :p
Kaz-Coder, sounds like it's
Kaz-Coder, sounds like it's time for you to be on the road! It's a good thing Siggraph is around the corner ... else you'll be liable to explode! 8P
C++ is dead... :-) now you
C++ is dead... :-) now you should create a new 3D engine using C# and .net pages!
emmm.. there is always going
emmm.. there is always going to be need for C/C++/ASM.
Making a normal 3D engine it's simple and can be done in any language.. doing the internals, doing something different, is not going to work so well if you can't access memory directly in the fastest (and most unconventional) way possible.
..time for you to reevaluate asm maybe ! 8P
I see the same thing
FWIW: I see the same behavior with visual studio 8. I click "find in files" and a window appears immediately, but unfortunately one must wait five seconds for the window to finish its epileptic seizure before it can be used. Efficient access to multiple files through "find in files" used to be a compelling reason to use Visual C++. Now I am left wondering if I should be using emacs, ultraedit, or (horrors) vim instead. You may say "whats the big issue with 5 seconds anyways", but if you working on big changes to a large code then you are constantly in and out of "find in files" and an entire day of waiting through these delays leaves the poor system programmer's nerves jangled.
PS: One could speculate (warning: speculations are easily clouded by personal biases) that MS spent some considerable time and money recoding this particular "find in files" popup in c#, and that maybe now they are starting to see that this was a mistake.
For the time being I suggest
For the time being I suggest using Visual Assist X's refactoring facilities. The Find References option can be accessed fairly quickly by hovering on a symbol.
The only problem is that it's not 100% accurate, especially when one starts using smart pointers and templates heavily.
In general, I just hope MS gets its act together. Support the veteran programmers instead of throwing in more bloat.
my workaround
FWIW, I noticed yesterday that find-in-files is slow here _only_ when I have multiple independent copies of visual studio 2008 running on my workstation. My system has 4GB of ram so perhaps the slowdown is caused by an issue in visual studio, and not running low on memory?
Visual Slowdio
I found that the find dialog gets up much quicker if I leave only a few files open.
Now, from time to time I close a bunch. I never really worried too much about closing source files before because I don't click on tabs anyway 8)
seems to be realated to windows vista aero
I just noticed that turning off windows vista aero also improves the situation
Post new comment