| T O P I C R E V I E W |
| pvercello |
Posted - Sep 07 2007 : 8:08:57 PM
Hi there,
VA_X 10.3.1559, devstudio 2005
I have a consistent problem that after I've been running VA_X for a few days, the Open File In Workspace command takes progressively longer to open up. During this time CPU usage is at 100% for one of the CPU's. This is with about 4500 files in the solution. When I first open the solution, the OFIW dialog opens almost instantaneously. After a day, it takes about 5 seconds. After two it's about 15 seconds. I don't have any timing beyond that.
Closing and reopening DevStudio and the solution fixes the issue.
cheers
Paul |
| 14 L A T E S T R E P L I E S (Newest First) |
| support |
Posted - Dec 16 2011 : 1:55:57 PM
Open Files in Solution performance issue is case=19139, and is fixed in build 1862 |
| accord |
Posted - Nov 15 2007 : 5:14:41 PM
I have experienced the same about a half year ago, and it was hard to find, why OFIW is getting slower and slower...
quote:
We have plans to change what it does in the future because it doesn't make much sense as it is now.
Sounds good!  |
| Rasmuss |
Posted - Nov 14 2007 : 02:56:36 AM
quote:
Originally posted by sean
Whether checked or unchecked all the files in the solution are listed.
When unchecked, it looks to see if any of the currently open files are not already included in the list. If so, they are added.
Ah, thank you. That explains why I saw the delay rise the more files I had open. |
| sean |
Posted - Nov 13 2007 : 11:50:20 AM
Whether checked or unchecked all the files in the solution are listed.
When unchecked, it looks to see if any of the currently open files are not already included in the list. If so, they are added.
|
| Rasmuss |
Posted - Nov 13 2007 : 03:48:19 AM
quote:
Originally posted by sean
The checkbox probably isn't doing what you think it is. We have plans to change what it does in the future because it doesn't make much sense as it is now. Do you actually notice a difference in the results when it is unchecked?
No, I haven't noticed any files I couldn't find, or anything like that (although I have only used it for a couple of days). The count in the title bar is the same as well.
Out of curiosity, can you tell me what the checkbox does? |
| sean |
Posted - Nov 12 2007 : 11:52:02 AM
The checkbox probably isn't doing what you think it is. We have plans to change what it does in the future because it doesn't make much sense as it is now. Do you actually notice a difference in the results when it is unchecked? |
| Rasmuss |
Posted - Nov 12 2007 : 04:34:05 AM
quote:
Originally posted by sean
It is possible you are experiencing two different unrelated problems. With a 5000+ file solution and 63 open files, the "show only files in current solution" checkbox could have noticeably different performance checked vs unchecked. So in theory, hibernation cycles should not be at play in the time it takes to open the dialog - should be easy to test.
You are correct. Enabling 'Show only files in the current workspace' improves the opening speed a great deal. I guess I'll work with that enabled from now on, in conjunction with restarting Visual Studio every night, even though I would like to be able to keep it open. |
| sean |
Posted - Nov 09 2007 : 2:57:04 PM
It is possible you are experiencing two different unrelated problems. With a 5000+ file solution and 63 open files, the "show only files in current solution" checkbox could have noticeably different performance checked vs unchecked. So in theory, hibernation cycles should not be at play in the time it takes to open the dialog - should be easy to test. |
| Rasmuss |
Posted - Nov 09 2007 : 03:06:35 AM
quote:
Originally posted by sean
Do you have "show only files in the current solution" unchecked in the OFIW dialog? If so, try checking the box.
I am now restarting Visual Studio as part of my hibernate script, but I will try to keep it open and check the box.
I do, however, think that there is still a leak somewhere, and while enabling that option might make the slowdown less obvious, it is still there.
My 0.02$ :)
|
| sean |
Posted - Nov 08 2007 : 11:03:41 AM
Do you have "show only files in the current solution" unchecked in the OFIW dialog? If so, try checking the box. |
| Rasmuss |
Posted - Nov 08 2007 : 09:24:08 AM
Hello,
I'm experiencing the same problem, but I seem to have isolated it to the amount of files open corresponding to the speed with which OFIW opens.
I do hibernate my machine, so Visual Studio has been open for quite some time, and the slowdown disappears when restarting visual studio.
With 62 files open, OFIW shows approximately 6 seconds after having pressed the OFIW button.
With 1 file open it shows in around .5 seconds.
OFIW reports 5530 files in the title.
quote:
Originally posted by feline
That's not much of a jump, I would not have expected such a noticeable slow down from so small an increase in memory usage.
Can you try running Process Explorer please:
http://www.microsoft.com/technet/sysinternals/utilities/processexplorer.mspx
and turn on the columns:
Process memory -> Working Set Size (this is memory used)
Process memory -> GDI Objects
Process memory -> USER Objects
I am wondering if the GDI or USER Objects count is going right up over time.
Here are my numbers for visual studio which has been running for a couple of days (hibernated every night).
With 1 file open:
Working Set Size: 361.540K
GDI Objects (handles): 821
USER Objects (handles): 491
OFIW open speed: ~0.5 seconds
With 62 files open:
Working Set Size: 359.828K
GDI Objects (handles): 828
USER Objects (handles): 1110
OFIW open speed: 6 seconds
Numbers from freshly restarted VS:
With 1 file open:
Working Set Size: 178.104K
GDI Objects (handles): 448
USER Objects (handles): 240
OFIW open speed: instant
With 62 files open:
Working Set Size: 179.352K
GDI Objects (handles): 557
USER Objects (handles): 847
OFIW open speed: instant
Regards,
Rasmus
License info:
VA_X.dll file version 10.3.1561.0 built 2007.09.13
Licensed to:
VA X: xxxioi.dk (45-user license) Support ends 2009.05.30
VAOpsWin.dll version 1.3.2.7
VATE.dll version 1.0.6.1
DevEnv.exe version 8.0.50727.762
msenv.dll version 8.0.50727.762
Font: Courier New 13(Pixels)
Comctl32.dll version 6.0.2900.2982
Windows XP 5.1 Build 2600 Service Pack 2
8 processors
|
| feline |
Posted - Sep 11 2007 : 07:32:37 AM
That's not much of a jump, I would not have expected such a noticeable slow down from so small an increase in memory usage.
Can you try running Process Explorer please:
http://www.microsoft.com/technet/sysinternals/utilities/processexplorer.mspx
and turn on the columns:
Process memory -> Working Set Size (this is memory used)
Process memory -> GDI Objects
Process memory -> USER Objects
I am wondering if the GDI or USER Objects count is going right up over time. |
| pvercello |
Posted - Sep 10 2007 : 7:26:53 PM
quote:
Originally posted by feline
Which OS are you using?
XP.
quote:
Are you hibernating the machine at the end of the day, or is it staying powered on 24 hours a day?
Staying powered 24 hours.
quote:
If you check the memory usage for devenv.exe is this going up over the days?
I am wondering if there is some obvious resource that is being used that might correlate with this effect.
Yes, I think so. I just checked, and when I first launch (and the dialog opens fast), usage is about 257MB. After a couple days, when it's going slow, usage is about 293MB. I'll check over the next couple days if the correlation shows any trends.
-Paul
|
| feline |
Posted - Sep 10 2007 : 07:16:28 AM
It sounds almost like some form of resource leak.
Which OS are you using?
Are you hibernating the machine at the end of the day, or is it staying powered on 24 hours a day?
If you check the memory usage for devenv.exe is this going up over the days?
I am wondering if there is some obvious resource that is being used that might correlate with this effect. |
