| T O P I C R E V I E W |
| joephish |
Posted - Jun 18 2010 : 05:41:41 AM
Hey guys,
Is it possible to tell Visual Assist to ignore particular directories of source/header files, despite the fact that they're included in the Visual Studio solution? Our team has a significant amount of code in the solution which is very rarely used, and it would help performance if we could tell Visual Assist not to parse them or to search for symbols in them.
Thanks! :-)
Joe |
| 7 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Jun 21 2010 : 11:38:39 AM
Excellent news 
Given the size of the solution, and the number of duplicate symbols I can see why you were having problems. I would not expect the size on its own to cause problems for VA, but 4.5meg is an unusually large solution. |
| joephish |
Posted - Jun 21 2010 : 08:50:53 AM
It's okay, I've made a new solution file for our projects which is massively slimmed down. Because the solution is independent from our compilation process, it's made no effect to what is built, it's just MUCH easier and quicker to edit :-)
The vcproj which I stripped down is now 179k instead of 4.5MB. Phew!
Thanks for the help and advice! |
| joephish |
Posted - Jun 21 2010 : 04:41:31 AM
Yeah, I've already turned off intellisense :-)
The performance problem isn't when loading the solution, it's more in general usage (switching files/alt-g/being given code suggestions etc). However, I wouldn't want to assume it's definitely Visual Assist which is causing the performance problems, since we have a variety of other tools running which could be the cause. I'm basically trying to eliminate possibilities.
The problem with the duplicate symbols is that my team keeps many files in the solution which aren't actually compiled, since we use a compiler outside of Visual Studio for the platform we're developing on. This means that there are PC implementations and game-console specific implementations of the same functions.
Also, we keep the source code of several different libraries and frameworks in the solution, even though we don't use them directly in the project at the moment. Of course, I can negotiate with my lead to see if I can get the references removed and that might help. They're in a different project in the solution from the main project that we edit day to day. |
| feline |
Posted - Jun 18 2010 : 1:48:22 PM
For the performance, depending on your IDE, you might find disabling the IDE's intellisense parser helps quite a lot:
http://docs.wholetomato.com?W133
When you have this alt-g problem, how are the duplicate symbols kept separate? Are they in different namespaces? "static" symbols that are local to a specific file? Different overloads of a function?
VA tries to understand the code well enough to avoid offering to many destinations on alt-g, so I am wondering why you are having this problem in your solution. |
| joephish |
Posted - Jun 18 2010 : 10:43:14 AM
Thanks for the help :-)
If you say that the solution doesn't affect performance, then fair enough - I'll believe you! There's probably other tools that we're using slowing it down.
However, another problem that we've had is that often there are multiple symbols with the same name... for example different implementations of functions for multiple platforms. Often when I alt-g for a common function name, visual assist comes up with many different alternatives. It would be useful to be able to exclude the ones we don't need for the code we're currently working on from the symbol search.
Is this possible at all? |
| feline |
Posted - Jun 18 2010 : 10:37:14 AM
Are you seeing a performance problem only when loading the solution, or at other times as well? There is no official way to tell VA to ignore part of your solution, but once the solution has loaded the size of the solution should not matter.
You could try turning off:
VA Options -> Performance -> Parse all files when opening a project
but this can have some side effects for Alt-g, since VA cannot be sure that it has up to date knowledge of the solution content. |
| joephish |
Posted - Jun 18 2010 : 05:43:11 AM
(we're using version 10.6.1823.0, if that helps) |
