| T O P I C R E V I E W |
| jackkemp |
Posted - Jul 22 2014 : 3:54:55 PM
VA_X.dll file version 10.8.2029.0 built 2014.02.24
DevEnv.exe version 11.0.60406.1 Ultimate
msenv.dll version 11.0.60315.1
Comctl32.dll version 6.10.7601.17514
Windows 7 6.1 Build 7601 Service Pack 1
16 processors (x86-64, WOW64)
Language info: 1252, 0x409, 0xf4
Platform: Custom
Stable Includes:
E:\\soft\\Microsoft Visual Studio 11.0\\VC\\include;
E:\\soft\\Microsoft Visual Studio 11.0\\VC\\atlmfc\\include;
C:\\Program Files (x86)\\Windows Kits\\8.0\\Include\\um;
C:\\Program Files (x86)\\Windows Kits\\8.0\\Include\\shared;
C:\\Program Files (x86)\\Windows Kits\\8.0\\Include\\winrt;
E:\\dev\\3rd\\boost_1_50_0\\boost;
Other Includes:
Stable Source Directories:
E:\\soft\\Microsoft Visual Studio 11.0\\VC\\atlmfc\\src\\mfc;
E:\\soft\\Microsoft Visual Studio 11.0\\VC\\atlmfc\\src\\mfcm;
E:\\soft\\Microsoft Visual Studio 11.0\\VC\\atlmfc\\src\\atl;
E:\\soft\\Microsoft Visual Studio 11.0\\VC\\crt\\src; |
| 3 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Aug 05 2014 : 10:57:35 PM
We keep an eye on speed, but remember, running inside a VM can add another layer of overhead. I do most of my testing inside VM's, due to the number of different OS's and configurations that we need to test, so am aware of and sensitive to these concerns.
One obvious bottle neck to watch for with virtual machines is the hard drive. If the host OS and the VM are both running on the same hard drive, this can bottle neck the system even without VA. The amount of resources you have allocated to the machine is also a factor. The more recent versions of the IDE desire quite a lot of RAM and CPU time before you add VA to the mix, and a 32bit OS is limited in how much RAM it supports. |
| foxmuldr |
Posted - Aug 05 2014 : 08:50:35 AM
accord, feline, I would like suggest a possibility to help track down this slowness as it happens also to me. I don't notice it as much when doing native development on a modern machine (Win7 64 3.x GHz processor), but most of my development is done inside a 32-bit VM under Linux Mint 64. While this is normally sufficient, the slowdowns seen in VAX are definitely more pronounced under that environment. And my guess is it may simply be a matter of needing to provide a higher priority to your main thread, and to post messages to secondary handlers so things are done in parallel while the main thread continues with normal UI. If you're already doing this, please forgive me. :-)
My suggestion is to add a macro at the start of each function, and at each return location. The start macro is determined by a compile time switch. It either does nothing, or records the GetTickCount() to a temporary variable which is based off the function name. The macros near the return operate similarly with the compiler switch, and compute the GetTickCount() - that_variable, and then record the function and results to a log file.
While this will itself slow down VAX, the result would be a graphical analysis over time showing how fast things used to be, and how much slower they are now. You can find out exactly which algorithms are slowing down that way.
Hope this helps. |
| accord |
Posted - Jul 22 2014 : 10:28:43 PM
Sorry to hear that.
- Does this problem continue to occur if you disable Visual Assist temporarily via VAssistX -> Enable/Disable Visual Assist X
- Does this occur in every file or just in specific (e.g. large) ones?
- Does this occur in every context, or just in specific methods?
- Is every character delayed, or you experience short "hiccups"? e.g. a short delay in every few second?
- Does this occur when you keep a short pause in typing? Visual Assist reparses the file when you stop typing, but normally this is fast and you should not notice it.
- Does it help if you rebuild your symbol databases via VA Options -> Performance -> Rebuild
- Can you please try creating a clean new win32 test project to see if the problem happens there?
I am trying to get a general picture about your problem in an attempt to narrow it down a little. |
|
|
