| Author |
 Topic  |
|
foxmuldr
Tomato Guru
USA
384 Posts |
 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! :-) |
Edited by - foxmuldr on Aug 05 2014 1:09:08 PM |
|
|
feline
Whole Tomato Software
United Kingdom
18751 Posts |
Posted - Aug 06 2014 : 2:19:44 PM
|
How many files do you have in your solution?
If you open VA's Open File in Solution dialog (Alt-Shift-O) the title bar contains two numbers. The first number is the number of files currently listed, which changes as you filter the list. The second number is the total number of files in the list, which is normally the number of files in your solution. What is this second number?
Are you working with a lot of files / tabs open in the editor? Or do you just have a couple of files open in the editor? I have seen reports where working with 100 open files at once is related to a slow down.
Can you try turning Off:
VA Options -> Performance -> Keep symbols in memory for fast response after Alt+Tab
and see if this makes any difference? |
zen is the art of being at one with the two'ness |
 |
|
|
foxmuldr
Tomato Guru
USA
384 Posts |
Posted - Aug 07 2014 : 11:23:42 PM
|
quote:
Originally posted by feline
How many files do you have in your solution?
36.
quote:
If you open VA's Open File in Solution dialog (Alt-Shift-O) the title bar contains two numbers. The first number is the number of files currently listed, which changes as you filter the list. The second number is the total number of files in the list, which is normally the number of files in your solution. What is this second number?
36.
quote:
Are you working with a lot of files / tabs open in the editor? Or do you just have a couple of files open in the editor? I have seen reports where working with 100 open files at once is related to a slow down.
It varies. I typically don't have more than 15 open. They were all open just now because I upgraded from version 0.46 to 0.47 in my app, and the global find-and-replace opened them all.
quote:
Can you try turning Off:
VA Options -> Performance -> Keep symbols in memory for fast response after Alt+Tab
and see if this makes any difference?
Will try. I did a lot of development tonight and did not notice a significant slowdown. However, I did not do a lot of new coding or refactoring. Most of it was debugging. The slowdowns seem to come when the undo buffer grows larger and larger.
Best regards,
Rick C. Hodgin
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18751 Posts |
Posted - Aug 08 2014 : 01:02:18 AM
|
Are your files very large, many thousands of lines long? Are you using very template heavy code?
This is a very small number of files, you should not normally be having these sort of performance problems in a solution of this size.
Which version of VA are you using? Are you only getting this problem under Windows 2000, or are you also getting this with the current version of VA? |
zen is the art of being at one with the two'ness |
|
|
|
foxmuldr
Tomato Guru
USA
384 Posts |
Posted - Aug 11 2014 : 6:24:45 PM
|
quote:
Originally posted by feline
Are your files very large, many thousands of lines long? Are you using very template heavy code?
This is a very small number of files, you should not normally be having these sort of performance problems in a solution of this size.
This is the project. It has a handful of files a few thousand lines long. It is not a huge project. I have written what you see here mostly since May: https://github.com/RickCHodgin/libsf/tree/master/source/vjr
quote:
Which version of VA are you using? Are you only getting this problem under Windows 2000, or are you also getting this with the current version of VA?
I'm using 1800-something in Windows 2000, and 2043 in Windows 2003 Server (VM), and Windows 7 (native Core i5 CPU). I have no observable issues when running on the native CPU, but when running in the VM in either Linux or Windows (VirtualBox 4.3.x, am currently running 4.3.14) it gets slower and slower, predominately as the undo buffer grows. If I periodically exit Visual Studio the problem goes away. It has occurred to me recently to only try closing the solution. If that's different I'll let you know.
The slowdown only becomes intolerable after many many changes are made. Up until then it just becomes progressively slower, and progressively more annoying. :-)
Here's the copy info content:
License: f---------------m (1-user license) Support ends 2014.10.15
VA_X.dll file version 10.8.2043.0 built 2014.07.10
DevEnv.exe version 9.0.30729.1 Professional
msenv.dll version 9.0.30729.1
Font: Ubuntu Mono 12 (pixels)
Comctl32.dll version 6.0.3790.5190
Windows Server 2003 5.2 Build 3790 Service Pack 2
Single processor (x86)
Language info: 1252, 0x409
Platform: Win32
Stable Includes:
C:\\Program Files\\Microsoft Visual Studio 9.0\\VC\\include;
C:\\Program Files\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\include;
C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\include;
C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\include;
Other Includes:
Stable Source Directories:
C:\\Program Files\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\src\\mfc;
C:\\Program Files\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\src\\mfcm;
C:\\Program Files\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\src\\atl;
C:\\Program Files\\Microsoft Visual Studio 9.0\\VC\\crt\\src;
Best regards,
Rick C. Hodgin
|
Edited by - foxmuldr on Aug 11 2014 6:26:54 PM |
|
|
|
feline
Whole Tomato Software
United Kingdom
18751 Posts |
Posted - Aug 11 2014 : 8:28:48 PM
|
Since this seems to be tied to editing, can you please check inside the directory:
C:\\Documents and Settings\\%USERNAME%\\Local Settings\\Application Data\\VisualAssist\
and look for the "History" directory, probably in the "vs8" directory, and see how many files are stored there. I am remembering a bug report about VA slowing down when it has stored a lot of file history, to be used to help with recovering your latest edit after a crash. This was fixed quite a while ago, but its possible your VM's are using an old enough version to still have this bug.
If this is the case then turning Off:
Visual Assist X Options -> Performance -> Enable Auto Recovery
may well help. |
zen is the art of being at one with the two'ness |
|
|
|
foxmuldr
Tomato Guru
USA
384 Posts |
Posted - Aug 11 2014 : 9:08:49 PM
|
The current VM I am using is a third generation install which uses a dynamic hard disk size (no other real differences from the other two previous ones). I found vs_7, vs_71, vs_9 and vs_91 directories. There were several files within, but none of them were very old. That VM version is not more than a couple months old. I've seen this slowdown behavior since at least October, 2012 when I was doing heavy development.
I will turn off auto recovery and see if that makes a difference. Thank you.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18751 Posts |
Posted - Aug 11 2014 : 10:01:54 PM
|
| With using such an old version of VA, its possible the problem has since been fixed, which is why you don't see it in the host OS. Or it is possible it is something about the hardware resources allocated to the VM's, or something else again. Normally the first step is to install the latest version of VA, but the OS's you are using won't support this. Sadly, this also means that even if a new, specific bug in VA was found, the fix would be implemented in our next version, which still won't help you since it won't support Windows 2000. |
zen is the art of being at one with the two'ness |
|
|
|
foxmuldr
Tomato Guru
USA
384 Posts |
Posted - Aug 12 2014 : 1:48:38 PM
|
| I am using 2043 in these current VMs. The only place I use the old version of VA is in the Win2K VM. |
|
|
|
foxmuldr
Tomato Guru
USA
384 Posts |
Posted - Aug 12 2014 : 1:55:39 PM
|
I haven't seen the editing slowdown issue in the Windows 2000 install because I don't generally do editing there. Just testing and debugging any issues which prevent the app from compiling in the older toolset. The slowdown I see in Win2K is because of the app/debugger launch slowdown with VA enabled.
It would be really nice if you could remove the DLL dependency so your current version of VAX would still work with Windows 2000. You could probably do it by switching your compiler tool choice settings to use the previous generation toolset rather than the latest. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18751 Posts |
Posted - Aug 12 2014 : 2:28:05 PM
|
Ah, OK, that's me getting confused. You will definitely have the bug fix I was thinking of, for a very large number of files in the history directory then. It would still be interesting to know if turning off:
VA Options -> Performance -> Enable Auto Recovery
has any effect, but I am no longer confident this will help. But I am not sure why you see such a slow down when editing... how much RAM have you allocated to the VM where you see this problem, with VA 2043?
As for changing to an older compiler, you loose the optimisations in the newer compiler, you loose support for any new language features added in the new compiler, etc. Going backwards is sometimes just not realistic without a lot of work. |
zen is the art of being at one with the two'ness |
|
|
|
foxmuldr
Tomato Guru
USA
384 Posts |
Posted - Aug 12 2014 : 9:45:33 PM
|
It's a compiler switch. You can try it and see if it works without changing anything. :-) If it doesn't ... then set it back. Most of the optimizations you'd lose are exceedingly trivial on code where things are cued off user input.
I'm reminded of that scene in Star Trek Voyager's "Pathfinder" episode where Lt. Barclay is trying to explain to Admiral Paris and Commander Harkins about his idea, but is being cut off before being given a chance. He says, "What do we have to lose by trying?" He was later proven correct, but he resorted to inappropriate behavior in the process.
In any event, I appreciate your help. I have gained a lot of knowledge about how to write a tool like VAX from my years of using it. I pray I'll be able to incorporate many of the same abilities into my IDE (James 4:15). |
Edited by - foxmuldr on Aug 13 2014 06:44:55 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
18751 Posts |
Posted - Aug 13 2014 : 5:07:23 PM
|
You are not even doing most of your editing under Windows 2000, and you are the only person who has reported using Windows 2000 for the last few years. Unfortunately this is simply not a useful use of resources.
If a single one off build was produced, this would only go out of date as soon as the next build was produced, returning us to this conversation all over again. The alternative is to add Windows 2000 to the list of supported OS's, so it would need to be considered, and tested, for every release. That is not a single, one off job, but an ongoing commitment.
Different OS's have different behaviours, and OS specific bugs do happen, so adding support for another OS is not "free". I am not trying to be deliberately difficult, even if it seems like it, I am simply trying to be realistic about available resources. This thread is actually about your performance problems with the current version of VA, under a newer OS, which sounds like a better problem to focus on and try to fix. |
zen is the art of being at one with the two'ness |
|
|
|
foxmuldr
Tomato Guru
USA
384 Posts |
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?
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18751 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
foxmuldr
Tomato Guru
USA
384 Posts |
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. :-)
|
Edited by - foxmuldr on Aug 20 2014 09:00:09 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
18751 Posts |
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? |
zen is the art of being at one with the two'ness |
|
|
|
foxmuldr
Tomato Guru
USA
384 Posts |
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. |
|
|
|
foxmuldr
Tomato Guru
USA
384 Posts |
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. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18751 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
foxmuldr
Tomato Guru
USA
384 Posts |
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). |
Edited by - foxmuldr on Aug 25 2014 08:10:23 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
18751 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
foxmuldr
Tomato Guru
USA
384 Posts |
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
Whole Tomato Software
United Kingdom
18751 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
foxmuldr
Tomato Guru
USA
384 Posts |
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. :-)
|
|
|
|
foxmuldr
Tomato Guru
USA
384 Posts |
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. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18751 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
foxmuldr
Tomato Guru
USA
384 Posts |
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)? |
Edited by - foxmuldr on Aug 25 2014 7:31:43 PM |
|
|
|
feline
Whole Tomato Software
United Kingdom
18751 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
foxmuldr
Tomato Guru
USA
384 Posts |
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
Whole Tomato Software
United Kingdom
18751 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
Topic |
|
|
|
Increasingly poor performance in VS2003, VS2008
