T O P I C R E V I E W |
bberry27 |
Posted - Mar 07 2006 : 2:39:23 PM VAX 1440 in VS2005 performance continually degenerates into horrible slowness. Visual Studio takes several seconds to print each character I type. Disabling Visual Assist instantly improves performance. I wait a while to enable it and I generally get about 5-10 minutes of barely acceptable performance until it spirals down again.
I've read on the forums that, if I read correctly, these are known issues and a new version is on the horizon. When might that be? This is painful.
BTW, I am running some new intellisense DLLs that the Visual Studio team gave me that fix the known performance issues in intellisense. If you have similar intellisense performance issues in VS2005, you can try emailing Ravi Uppaluru ([email protected]) and see if he'll give you the fixes. These are slated to be included in the upcoming VS2005 Service Pack later this year.
Right now VAX is definitely the performance culprit and I'm really hoping for some fixes soon so we (40 engineers) can continue to use the product. |
13 L A T E S T R E P L I E S (Newest First) |
support |
Posted - Mar 12 2006 : 5:01:50 PM We agree with feline. Logs files will likely help.
Sample code to repro the slowness is another option. |
feline |
Posted - Mar 11 2006 : 11:58:03 AM true. however VA is a lot more complex under the hood than most other programs, due to the way it has to hook into the IDE in many different places. this means that each option generates a lot more code than you would expect.
you can try turning off the existing options to see if that helps, colouring of the editor being an obvious place to start.
assuming that you see this performance problem instantly can you load the IDE, turn in VA's logging
http://www.wholetomato.com/support/faq.html#log
and then make some basic edits for a few minutes, before quitting the IDE and sending the log files to [email protected] , referencing this thread. the log files get large quite quickly, but hopefully this will provide some clues as to the source of the problem. |
bberry27 |
Posted - Mar 10 2006 : 4:06:47 PM An option to turn off macro parsing would be helpful to track this down. In fact a general debug tab that allowed us to to turn off various parsing features would be even better. |
feline |
Posted - Mar 10 2006 : 3:07:28 PM *sigh*
some complex macro's have been known to bring VA to its knee's, so this is possible. does your code use a lot of macro's? to put this in perspective i recall one bug where 5,000 macro's in a row caused problems.
very complex macro's could also be a problem, even if you are only using one or two of them. |
bberry27 |
Posted - Mar 09 2006 : 7:45:28 PM The only thing I can think of is that working with/near macros seems to be worse than not, but that's just a suspicion. I've had VAX disabled all day because I'm writing a lot of code... :( |
feline |
Posted - Mar 09 2006 : 5:30:13 PM none of those really leap out at me to be honest. are there any clues you can offer? does this appear to happen more often in some files than in others?
with template bugs it is fairly common to find that some code files have a lot of problems while other files have no problems. |
bberry27 |
Posted - Mar 09 2006 : 2:01:25 PM It improved performance but I wouldn't call it 'fixed'. I still find the editor to be sluggish when VAX is enabled. |
Sasa |
Posted - Mar 08 2006 : 11:39:30 PM bberry27, did the latest build fix this issue for you? |
bberry27 |
Posted - Mar 08 2006 : 8:15:24 PM Here's a list of some of the stuff we use from both boost and the standard library. It's not complete, but gives you a rough idea of what we're using.
boost::thread boost::bind boost::shared_ptr boost::weak_ptr boost::mutex boost::mutex::scoped_lock boost::function boost::barrier boost::scoped_ptr boost::filesystem boost::call_once boost::recursive_mutex boost::once_flag boost::noncopyable boost::is_const boost::is_convertible boost::remove_const boost::static_pointer_cast boost::has_trivial_destructor boost::ptr_vector boost::algorithm::split boost::condition boost::algorithm::is_any_of
std::string std::map std::list std::set std::vector std::swap std::make_pair std::find std::copy_backward std::copy std::runtime_error std::wstring std::pair std::sort std::for_each std::remove_if std::fill std::auto_ptr
|
feline |
Posted - Mar 08 2006 : 7:11:28 PM from your post in the VA 1442 release thread:
quote: Here's a couple of key data points: * VS: Good Performance * VS+IS: Periodic sluggishiness. * VS+VA+IS: Frequent and severe sluggishness. * VS+VA: Frequent and severe sluggishness. * VS+IS2: Good Performance. * VS+VA+IS2: Frequent and severe sluggishness.
(Legend: IS = Intellisense IS2 = Fixed Intellisense DLLs from Microsoft) VA = Visual Assist VS = Visual Studio 2005)
The only common factor for "Frequent and severe sluggishness" is Visual Assist.
i work with a larger C++ code base myself and do not see this problem, which suggests that the number of files its self is not the problem.
is there any pattern to the files you are editing? are .h files normally acceptable speed? how about cpp files? i am looking for any form of pattern to help point us in the right direction.
you mention both the "standard library" and boost. are you using the STL classes that ship with the IDE or the boost versions? which boost features are you using, and which version of boost do you use?
do you have any small test projects? if so have you ever seen any speed problems there? |
support |
Posted - Mar 07 2006 : 6:04:06 PM We suspect parsing of templates was making the IDE slow to a crawl. Try build 1442:
http://www.wholetomato.com/downloads/VA_X_Setup1442.exe |
bberry27 |
Posted - Mar 07 2006 : 3:31:16 PM * It's a large C++ code base I'm working with, about 10,000 files. * Previous versions of VAX have not been a problem. * VAX on VS2003 is not a problem. * I have tried the disabling Intellisense as you've mentioned and it did not help other than to eliminate the Intellisense specific performance problems which are definitely distinct from the VAX issues. VS2005 will still slow to a crawl with VAX enabled and run swiftly as soon as I disable it. * We use templates primarly with the Standard Library and we use a couple of Boost features.
|
feline |
Posted - Mar 07 2006 : 3:20:09 PM off the top of my head the only such speed issues with VA are related to certain template heavy C++ code. most forms of this bug are file specific, i.e. it happens when you open one of the problem files, but does not show up in other code files. do you see this effect on your machine?
are you using C++? i work on a fairly large C++ solution in VS2005, and even without VA installed i can get a similar experience. the only way i fixed this was to stop the IDE's intellisense running by creating two zero length read only ncb files.
it is possible there is some form of clash between VA and these new intellisense dll's, and since they are not on general release we will not have tested against them.
if your problem does not seem to be file specific or related to C++ templates then can you try the following. first test, open the OFIW dialog (CTRL-SHIFT-O) and see if it lists files? if it says "parsing..." on the title bar and is empty then VA is still parsing your code base and could well the the issue. however if you get the files then VA has finished parsing.
if VA is not parsing then can you try quitting the IDE * replace your ncb file in the solution base directory with a zero length read only ncb file * copy this ncb file to the %TEMP% directory * reload the IDE and tell it to leave the ncb file alone when you load the solution
this should eliminate the IDE's intellisense from the picture, it does with VS2005 in its base state.
if you still get the speed problems we are expecting a new build of VA in the next couple of days that should have the C++ template fix in it. |