| T O P I C R E V I E W |
| foxmuldr |
Posted - Aug 05 2014 : 08:40:04 AM
I run Visual Studio 2003 and Visual Studio 2008 with VAX on Windows 2003 Server primarily, but also Windows 2000 Professional. I have observed that the longer I'm in Visual Studio working, the slower things get.
When editing, it happens mostly when I'm doing a large number of changes and the undo history grows, especially if I do some refactoring that might change a couple hundred things.
When debugging, I don't know what happens but the time to launch an application goes from 1-2 seconds to well over 20 seconds. If I disable VAX it is back down to 1-2 seconds.
My workaround is to disable VAX when I get ready to debug my program. This works, but is clunky because VAX is so handy and it's the extra step of turning it off, turning it on, doing my thing, turning it off, debugging, turning it on, etc.
If you have a diagnostic version of VAX that records GetTickCount() differences on entry and exit of internal functions, I would be willing to install that version and do some of my development to the point where it begins to slow down and then send you the log file so you can find out what is taking so long to process. The editing one takes a couple hours. The debugging slowdowns occur almost immediately, but certainly within the first 10 or more instances of restarting the application during development.
Thank you! :-) |
| 30 L A T E S T R E P L I E S (Newest First) |
| foxmuldr |
Posted - Nov 07 2023 : 10:22:01 AM
I am a very fast typist and it doesn't happen right away. But if you're working in Visual Studio for a few hours you'll see the effect accumulate over time. Also, if you're working in a Virtual Machine you'll see the effects more quickly. Takes at least 30 minutes of development for it be noticeable, and well over an hour before it is an issue. |
| feline |
Posted - Oct 31 2023 : 12:14:33 PM
At a wild guess, sounds like something that got "fixed" in newer versions of Visual Studio, but I don't remember running into this back when I worked full time in these versions of Visual Studio. Thankfully you have a work around, even if it isn't something that should need to be done. |
| foxmuldr |
Posted - Oct 31 2023 : 11:22:37 AM
I later found the issue. It's due to maintaining a history of navigation and/or an undo history. I'm guessing it's using a root element and a one-way linked-list to add the new items, traversing the entire list to add the new entry, which is why it increasingly slows down.
The workaround is to periodically close the file and re-open it.
I have observed this in VS 2003, 2005, and 2008.
--
Rick C. Hodgin
|
| foxmuldr |
Posted - Sep 01 2014 : 1:54:47 PM
At this point in both cases I'm not going to worry about it. The performance degradation is a daily issue for me ... but it's not a big issue, and certainly not enough to spend time tracking it down like this. I'd lose more time tracking it down at this point than just living with it.
I'm not sure why I see it in the VM only, and not on OS versions running natively on the CPU. It seems odd, but the other advantages from running VMs far and away exceed the losses. In fact, I would say this is the only loss I have thus far ... and with me working on developing my own IDE and C/C++ compiler, it's not one that will be with me for long (Lord willing). :-)
Thank you for your assistance and patience, feline. If you all ever have a Whole Tomato meetup somewhere... I'd like to attend (with my American accent and all, y'all). :-)
|
| feline |
Posted - Aug 31 2014 : 2:45:37 PM
Then its worth considering turning Off:
VA Options -> Listboxes -> Get content from default Intellisense
and if you can work like this successfully, disabling the IDE intellisense, to see if this makes any difference. |
| foxmuldr |
Posted - Aug 30 2014 : 8:23:36 PM
I did download Process Explorer ... even back the first time you suggested it. :-) I've run it several times. I hadn't seen any advantages in what it shows over task manager until your post above. It shows what Task Manager reports: When the slowdowns occur, the devenv.exe process is pegged at around 25% (with four CPUs allocated to the VM, that 25% means one CPU running at 100% utilization). It peaks on the graph for the duration of the slowdown, and then returns. Turning off VAX seems to make no difference, or possibly a small difference. It seems to be a VS thing related to having the large files open.
I have seen the slowdown effect now on two different machines running two different VMs on two different versions of Linux Mint (one LM 16, the other LM 17). It occurs when I'm doing editing for more than a few minutes on this file (I've been working on the block around line 1500 for the past several days, and I've had four files open):
Main work file: https://github.com/RickCHodgin/libsf/blob/master/source/vjr/object_accessors.h
File 2: https://github.com/RickCHodgin/libsf/blob/master/source/vjr/object_accessors.cpp
File 3: https://github.com/RickCHodgin/libsf/blob/master/source/vjr/vjr_const.h
File 4: https://github.com/RickCHodgin/libsf/blob/master/source/vjr/compiler_const.h
|
| feline |
Posted - Aug 30 2014 : 4:44:49 PM
Can you please try running Process Explorer. Once it is loaded, right click on the column headers and use "Select Columns", and then go to the Process Performance tab, and turn on "CPU History". This will help identify which processes are using all of the CPU time when you get a slow down like this. |
| foxmuldr |
Posted - Aug 29 2014 : 3:05:27 PM
I did about 1.5 hours worth of nonstop editing last night on a 4,000 line source file. From time to time after the first 30 minutes or so it would become as slow as it ever has. I brought up task manager after the 5th or 6th time and it showed one CPU fully pegged in red coloring. The other three were very near idle. This would continue for 10 to 15 seconds, then it would revert to normal processing for a seemingly random period of time.
I've never seen that behavior before. It's always just gotten slower and slower. I have observed that on that laptop ever since I got my new router from time to time in the native Linux, and on other machines running native Windows 7 and Linux, they seem to do that from time to time -- almost freeze, but not exactly. Makes me wonder what's going on there under the hood with that new router.
|
| foxmuldr |
Posted - Aug 28 2014 : 04:08:21 AM
I've been sick. I haven't forgotten. I downloaded Process Monitor 16.something. It shows 4 cpus now (I upped it) and limited memory and cpu use. I will get to the video when I am feeling better. Please bear with me. :-) Gracias. |
| feline |
Posted - Aug 26 2014 : 7:42:50 PM
I am glad you have found a solution to the first problem. For the debugger, it may well be worth trying process explorer, and looking at the system usage information, to see if this throws any light on the situation. |
| foxmuldr |
Posted - Aug 26 2014 : 6:45:53 PM
However... it still did not fix the debugger slowdown. |
| foxmuldr |
Posted - Aug 26 2014 : 6:31:03 PM
I've solved the editor slowdown!!! It had to do with the HAL only recognizing 1 CPU and all of the threads trying to run on that CPU. I went through the instructions on this page and now it recognizes more than one CPU. When I did the pasting of the 25,000 + source code lines, there was no slowdown at all.
http://www.storagecraft.com/support/forum/only-1-processor-showing-task-manager
-------------------
This is a Windows Server 2003 solution. The short version of the solution is here:
Download devcon.exe from:
http://support.microsoft.com/kb/311272
Run it, which unzips and creates an i386\\devcon.exe file. That's the reference below.
-------------------
(1) Create a batch file and run the commands below.
Make sure there are no errors reported.
(2) Go to My Computer -> Properties -> Hardware ->
Device Manager -> expand Computer and click
"Update Driver". Specify that you will indicate
the location, and select the Multi ACPI driver.
(3) Reboot.
-------------------
SET HAL=ACPIAPIC_MP
i386\\devcon.exe sethwid @ROOT\\PCI_HAL\\0000 := !E_ISA_UP !ACPIPIC_UP !ACPIAPIC_UP !ACPIAPIC_MP !MPS_UP !MPS_MP !SGI_MPS_MP !SYSPRO_MP !SGI_MPS_MP
i386\\devcon.exe sethwid @ROOT\\ACPI_HAL\\0000 := !E_ISA_UP !ACPIPIC_UP !ACPIAPIC_UP !ACPIAPIC_MP !MPS_UP !MPS_MP !SGI_MPS_MP !SYSPRO_MP !SGI_MPS_MP
i386\\devcon.exe sethwid @ROOT\\PCI_HAL\\0000 := +%HAL%
i386\\devcon.exe sethwid @ROOT\\ACPI_HAL\\0000 := +%HAL%
i386\\devcon.exe update %windir%\\inf\\hal.inf %HAL%
i386\\devcon.exe ReScan |
| feline |
Posted - Aug 26 2014 : 2:52:57 PM
Like I said, I have nothing against humour, I just try to keep things clear, especially since not everyone I talk to has English as a first language, plus my sense of humour can be a bit different to some peoples 
Can you please download and run Process Monitor:
http://technet.microsoft.com/en-gb/sysinternals/bb896653
inside the VM. I am particularly interested in the CTRL-I, system information screen, which provides a useful overview of your system, and will make it easy to see if you are running into any obvious resource limits when the slow down happens, for example CPU or hard drive maxed out, or all of your memory used. |
| foxmuldr |
Posted - Aug 26 2014 : 07:49:03 AM
quote:
Originally posted by feline
A sense of humour is a subtle thing, and its often best to stick to facts when trying to pin down a problem report.
http://www.psychologyofgames.com/wp-content/uploads/2011/12/sad_panda.jpg
quote:
For the debugger, are you working with edit and continue? That might be a factor.
Si. Si. Edit and continue. Si.
quote:
Have you tried defragging inside the VM, and outside the VM as well? Hard drives don't seem to need defragmenting like they used to, but its a thought.
Yes. When I start out it goes more or less normally. It is only after I go through several cycles that it gets slower. I'll record a video and demonstrate (pronounced with a long "o" and extra emphasis on the "mon" syllable, deMONstrate).
I tried, feline. But I couldn't resist adding in the humor. Please accept my apologies. :-) |
| feline |
Posted - Aug 25 2014 : 8:29:52 PM
A sense of humour is a subtle thing, and its often best to stick to facts when trying to pin down a problem report.
For the debugger, are you working with edit and continue? That might be a factor.
Have you tried defragging inside the VM, and outside the VM as well? Hard drives don't seem to need defragmenting like they used to, but its a thought. |
| foxmuldr |
Posted - Aug 25 2014 : 7:26:45 PM
I realize that, feline. I was, of course, joking. It makes me sad to have to explicitly say that because I thought we were so into the witty repartee ... what with our ongoing back and forths. :-)
My VirtualBox 4.3.12 VM has 2 CPUs allocated to it, and 2GB of RAM. Windows Server 2003 boots up consuming 142 MB of RAM. I quote a variation of Dan Rydell's response to Casey McCall, "the length of this thread is way out of proportion to my level of interest in it." :-) I.e., the editing slowdown is no longer an issue for me since I have a workaround. I was just trying to convey the issue so it could be addressed. But, after realizing it is not an issue related to VAX, but rather something to VS itself... the desire to fix it has past.
So ... do you have any thoughts on why it takes so long to launch the debugger after a few launch/stop/edit/compile cycles (with an occasional apply code changes in there)? |
| feline |
Posted - Aug 25 2014 : 5:30:14 PM
Solution size is not a reflection of ability, but it is a reflection of the amount of code to parse, and the IDE's overheads. Since your overheads seem so small, there should be no major speed problems here. The fact that you are seeing problems even without VA suggests, but does not prove, that the allocated resources to the VM may not be sufficient.
Which is why I wanted to know about the CPU usage inside the VM, hard drive usage inside the VM. It also makes sense to check CPU usage and hard drive usage in the host OS.
This is also why I asked about disabling the IDE intellisense, since removing this parser from the situation should simplify things, and hopefully speed things up for you. |
| foxmuldr |
Posted - Aug 25 2014 : 2:22:04 PM
I could snail mail you a copy of my VM and you could try for yourself. Perhaps it's a VS or VAX setting. Perhaps it's a VirtualBox setting. Perhaps it's me running them on AMD64 CPUs instead of Intel CPUs. :-) If interested, email me. |
| foxmuldr |
Posted - Aug 25 2014 : 2:18:03 PM
"but the fact remains your solution is tiny by the standards of most solutions our users work with."
It's most likely because I'm an inferior developer. :-)
|
| feline |
Posted - Aug 25 2014 : 12:57:14 PM
It is perfectly possible to get good solid performance, running the IDE inside a virtual machine, but you need enough resources allocated to the VM. I use VMware workstation here, and my Windows 7 VM's are allocated 2 or 4 CPU's, and 4 gig of RAM. Older OS's, with fewer IDE's are allocated fewer resources.
In my experience, the normal bottle necks on VM performance are the hard drive and not allocating enough RAM.
Clearly you are seeing serious problems, even without VA.
A 28,000 line file is going to slow things down, especially when pasting in tens of thousands of lines of code. Still, this does not explain this level of performance problems. I still wonder if disabling the IDE intellisense parser will help, but the fact remains your solution is tiny by the standards of most solutions our users work with. |
| foxmuldr |
Posted - Aug 25 2014 : 12:01:50 PM
The final version I'm using is a little over 28,000 lines.
See: https://raw.githubusercontent.com/RickCHodgin/libsf/master/source/vjr/object_accessors.cpp
Everything after the top comments, from "bool iObj_set_activeColumn(SObject* obj, SVariable* var)" on, was added to what was originally about 3,000 lines of code. Since this has new code been created, the old code has been deleted/replaced by it.
When I pressed Ctrl+V, the IDE became non-responsive for about 90 seconds, and then it was operating like normal, but it took about one full second to process any typing keystrokes. I do not see the same slowdown when running in Win7 using the native CPU. I have observed it gets slower and slower when I begin pasting that 28,000+ block of code repeatedly, but even after pasting it four times it does not become notably slow when typing, even when just typing gibberish as fast as my fingers can go on the keyboard. I am sure it has something to do with running inside the VM, and I'm guessing it's because the VM is many times slower due to emulated RING-0 operations, than the native CPU in execution in the native OS since it runs directly on hardware.
I regularly delete the .NCB files (at least each push to GitHub, and sometimes more frequently). I have created a batch file which deletes all of the files I don't want to push to GitHub. See: https://github.com/RickCHodgin/libsf/blob/master/source/vjr__clean.bat
I appreciate your help. I'll try to track down the cause of the debugger launch, and apply code changes when VAX is enabled.
|
| feline |
Posted - Aug 25 2014 : 11:20:24 AM
How large was your large cpp file in the end? I have a large cpp file for testing VA in long files, which is 23,000 lines long. So while adding 10,000 lines to a file is a LOT of lines, on its own it does not push you into unknown or impossible territory.
Even in a file this big, performance should not be this bad with a modern version of VA.
VA does not know about the debugger, and does not get involved, in VS2008 and earlier. So debugging should not make any difference to VA's performance, since we are only interested in the editor and your code files.
As a first step can you please exit all instances of the IDE, and then locate the .NCB file in the same directory as your .SLN file. Once you have found this, delete the .NCB file. This is the file the IDE stores its intellisense database in, and I have occasionally seen this file become corrupt, which can produce performance problems or even IDE crashes. This file will be recreated when you next load your solution, so deleting it won't cause any problems, just a temporary slow down while it is being rebuilt. |
| foxmuldr |
Posted - Aug 25 2014 : 07:52:47 AM
This weekend I had occasion to add some generated code to my project. I created a custom tool to take some source data and translate it into C/C++ source code, kind of like how SOAP works. In any event, it added over 10,000 lines of code to a single source file. I was immediately able to observe that with that many new lines of code added, the response was unbearably slow (one character per second typing speed). I then turned off VAX to see if it made a difference and it DID NOT. I turned VAX back on and it was the same. I then closed the solution, exited out of the IDE, restarted VS2008, reloaded the solution, and the files automatically re-opened, but the speed had returned to normal. I realized then the editing slowdowns are not the result of VAX but something Visual Studio is doing internally, which seems related to either undo buffers, or newly added lines.
Note, however, that these editor slowdowns are independent of the debugger slowdowns which do seem to be the result of something in VAX, or some combination or coordination of function calls between VS and VAX during debugger launch / app startup, and the application of any code changes with "Apply Code Changes" and what is presumably some type of debugger launch or "app restart" following the code changes (to re-synchronize the new PDB with the new ABI in the already-loaded debugger instance). |
| feline |
Posted - Aug 21 2014 : 1:35:23 PM
Can you try turning Off:
VA Options -> Listboxes -> Get content from default Intellisense
for a couple of days, and see if this works acceptably for you? If this did work, then it would open the door to disabling the IDE intellisense parser, which would be an interesting test. Given your solution size its tempting to say having both parsers running should not be a problem, but clearly something is going badly wrong here. |
| foxmuldr |
Posted - Aug 21 2014 : 07:33:58 AM
Next time I see them occurring during development I'll start my recorder and post some video. You can see what it's doing, along with the CPU usage, etc. |
| foxmuldr |
Posted - Aug 21 2014 : 07:07:23 AM
The slowdowns are observable within the first hour during heavy development (lots of refactoring), but typically not for a couple hours of normal development. They are slowdowns at first. Eventually, after 4+ hours of solid heavy development, they would get to the point where it is causing an issue with typing. Back then I didn't know of any workaround and I hadn't identified the cause yet. Now I know when it starts to get to a stopping point, and then exit VS and restart, then everything's good to go for a while.
Get content from default Intellisense is turned On.
My desktop has two hard drives. My laptop has one hard drive. I see the same effect over time on both, and I have run the VMs on both hard drives at various times. I currently boot into Linux Mint 16, and then run VirtualBox from there, which launches my Windows Server 2003 or Windows 2000 Professional OS versions.
I will look to see what CPU usage devenv.exe has when the slowdowns occur.
I do not use any anti-virus software inside the VM. I don't use the VM for anything other than development and push/pull to GitHub. And, because it is a VM, and because all of my source code is backed up and maintained in other places as well, should it ever get a virus, I would just delete that instance and copy over from one of my backups. |
| feline |
Posted - Aug 20 2014 : 1:50:06 PM
In summary, you are seeing the IDE slow down so much typing is unreliable after only an hour of development time! This is a massive slow down, happening almost instantly, in a solution, that by some standards, is absolutely tiny. There has to be something serious going on here.
We do take performance seriously, but you have to remember that we are operating "inside" the IDE, and this complicates matters.
Since you seem to be the only person seeing something like this, it suggests it is somehow system or situation specific. Lets go back to basics. Do you have:
VA Options -> Listboxes -> Get content from default Intellisense
turned On or Off? If this is turned Off can you please try disabling the IDE's intellisense, as explained here:
http://docs.wholetomato.com/default.asp?W133
Only having one parser to consider will simplify things a bit.
Does your system have more than one physical hard drive? If so, are you able to move the VM files onto a different physical hard drive to your boot drive?
When you see the slow down, can you check the CPU usage of "devenv.exe", also check for hard drive activity? Is the CPU or the hard drive maxed out?
What, if any, anti-virus are you using inside the VM? |
| foxmuldr |
Posted - Aug 20 2014 : 07:01:01 AM
My thinking is presumably there will be little difference between WinXP and Win2K, just that some of the requirements in the various DLLs have changed. Since your plugin is designed to work around particular versions of VS, then the host OS should not be a huge limiting factor, just the compiler toolset used to generate the executable need be changed. But, as you've said, it's not a native C++ app so there are probably other dependencies at work.
As for the slowdown: It depends on the number of changes. If I load my project and do some massive refactoring (renaming a bunch of structure members in use by many functions) you can see it very quickly. Typically it takes an hour or more of "normal" development to show up. You can see it in some of the videos I recorded back in November 2012 during my coding sessions: http://www.visual-freepro.org/videos/. If you skim through you'll find places where you can see me typing, and it's even reversing the input characters because it takes so long to receive each keystroke. I type "void functionxyz(void)" and what gets typed in is "ovdif nutcoixnzyv(io)d" for example. It's not quite that overt, but several of the characters are reversed on a regular basis. I didn't know what was happening back then so I just began typing slower when it would start. Or backspacing and correcting the errors.
Back then I had 8 GB allocated to my hard disk partition with about 6 GB in use. Today, I have 200 GB allocated with about 16 GB in use (the extra space is mostly snapshot backups made by date, and I didn't delete whatever the update process left when it went from VS2008 to VS2008 SP1, for example). The IDE is closed several times per day, however the virtual machine is simply paused when I exit, and when I restart. I only pause after I have saved my solution and exited out of VS because I typically push to GitHub before closing, and there are some files VS keeps open I have to exit out to release their file locks.
The machine back in 2012, and every machine since, has been allocated between 1GB and 2GB of RAM. I use both 1GB and 2GB machines today, and they both exhibit the same behavior.
I have Enable Auto Recovery turned off.
The VM instances of Windows Server 2003, and Windows 2000, are rebooted with some regularity, but not daily. I would say once a week or more they're rebooted. It's typically only when I want to make a hard backup of the VM, or when I need to change a setting, which I don't do very often. I have the VM CPU capped at 95% presently by a VirtualBox setting, but I have not had it capped in the past. I have devoted one and two cores to the VM at various times. I am using a developer version of Windows 2003 Server that came with VS2008, and I'm not sure it's recognizing multiple CPUs anyway because I don't notice any speed change, and Task Manager doesn't show more than one CPU. However, I've also read where that was a bug in Windows Server 2003's Task Manager. None of these changes or settings seems to make any difference in the slowdowns, or when they occur. It seems to be after a lot of changes are in the undo buffers... but that could be anything (memory fragmentation relating to paging on the host, etc).
As I say, I do not get observable slowdowns on my native Windows 7 x64 OS using the same version of VS2008 with the same service packs and VAX versions. However, I have also observed that for my own application I've been writing (http://www.libsf.org/software/vjr_0.51.1.zip as of the time of this post), to launch the app in my VM takes between 2 and 4 seconds. The same takes less than 1 second to launch on the Win7 machine. And since the slowdowns in VAX are only observable after a couple hours of heavy development, and they are typically only slowdowns, I'm guessing faster machines are seeing the slowdowns, but they aren't yet observable compared to people's typing speed.
You mentioned you pay close attention to performance... but is that usable performance, or measured performance? If you add measurements which can be enabled or disabled by a switch, then a log file could be created showing how long each function takes (in clock cycles on the machine), and then that information could be graphed over time during large periods of development. It would demonstrate where slowdowns are coming from. I would be willing to do this, and return the information to you, so you can see what algorithms are taking longer and longer to process... and then determine if it's the result of something inside VAX, or something in the OS or VM, or a combination of both.
I've seen a few posts where people talk about poor performance, but I haven't read another one about a growing slowdown observed over time. As such, and following your lead, it may not be a good use of slim developer resources to pursue this for one user who only sees the issue in a VM, and even then only on OS versions that are 10+ years old, and a version of VS that is at least three revisions out of date, and even then who has a workaround to exit the VS instance and restart.
In every way I'm very happy with VAX. It's made VS usable in almost Eclipse/Netbeans ways. If you never released another version I'd continue to use it. Again I say, thank you for writing it. :-)
|
| feline |
Posted - Aug 18 2014 : 12:55:39 PM
If I understand correctly you want official, ongoing support of Win2k, which will mean testing all new builds against Win2k plus investigating and fixing any Win2k specific bugs that come up. Can you see that this is a significant, ongoing commitment, and all for just one user, who is not even using Win2k as their primary working environment?
Returning to the slow down, this is your Server 2003 virtual machine? How much RAM and hard drive has been allocated to this machine? How much free space do you have on the hard drive?
Your solution is tiny. Approximately how long does it take for this slow down to show up? 2 hours? 2 weeks? 2 months? What sort of up time are we looking at in the IDE? Are you suspending the virtual machine between editing sessions? I am wondering if this is an OS or resource problem, since unless you have a massive up time, the undo buffer makes very little sense. If that was the case we should be getting reports from all over about this, but we are not.
Do you have:
VA Options -> Performance -> Enable Auto Recovery
turned On or Off? I see I have asked about this before, but it's not clear if you are working with this turned On or Off. |
| foxmuldr |
Posted - Aug 18 2014 : 11:30:42 AM
I was not suggesting a one-off build, but rather a reversion to the prior toolset which, if it worked, would automatically provide Win2K support without any changes. The losses you gain in optimization with the newer toolset are, in my opinion, trivial compared to the ability to have your product work with Win2K. But, that's my opinion.
I have continued to see the slowdown during heavy development. It gets slower and slower and slower until I close the solution, or exit VS, and then re-open the solution. I believe it has to do with maintaining larger and larger undo buffers, but I can't be sure. Does VAX traverse some kind of linked list to find some of its data? If so, you might consider storing both the first and last pointers and being able to then immediately jump to the end.
Is there anything else I should try?
|
|
|
