| Author |
 Topic  |
|
|
jmihalicza
Ketchup Master
Hungary
66 Posts |
 Posted - Sep 12 2005 : 1:11:51 PM
|
Having 1422 installed it takes 30 seconds to close 15 files on a P4 3.0GHz (measured right now). 
As I use 'Close all documents' quite frequently this is very annoying, I am considering switching back to 1418. 
The source files are actually on another machine next to me, I access them through a share (before you ask, it is for multiplatform development, the other machine is a Mac), but I have never had any problems with this before 1422. |
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Sep 12 2005 : 4:59:19 PM
|
do you have a project with local files? if not could you copy a selection of files onto the local hard drive and retest this?
i have just tried window menu -> close all documents in VS 2003 with VA 1422 and the speed is fine. these documents are local, since this machine is not really on a network.
bit of a long shot, but any anti-virus installed that could be having an effect? |
zen is the art of being at one with the two'ness |
 |
|
|
jmihalicza
Ketchup Master
Hungary
66 Posts |
Posted - Sep 13 2005 : 06:16:35 AM
|
It is the same with the local project in VS2003.
If VS2005B2 is open with the networked project another VS2005B2 fails to load (hangs on startup). I don't know whether it has to do sg with VA1422 though.
AntiVirus software - as all other sw/hw configuration - has been the same earlier without any problem.
A long shot, now from me, maybe there are extra parsings for each file when they are brought forward as a result of the close of the others.
The delay per file at close is the same as the delay when just Ctrl+Tab and wait for the VA bar to be refreshed.
I also noticed the same slow close behavior when I closed all but 2-3 windows using the Windows dialog (another frequent case).
In the case of Ctrl+Tab or normal single close it is ok, since any input operation (I mean keyboard or mouse click) aborts it. However when more 'bring document forward' actions take place I can't abort these 1-2 seconds refreshes since input is off for the time of the command. Maybe VA should do this refresh only when input is on, there is no sense refreshing the VA bar when there are subsequent other documents to bring front immediately afterwards.
I just tried other things: in the case of Ctrl+Tab and ALT+O I can abort the refresh with input events, but not in the case of Ctrl+F4 or clicking on the X. In these latter cases I have to wait 2-3 seconds to have control again.
I guess it happens only to me because there are lots of files with lots of symbols in my project, but I think this shouldn't knock VA out, and there were no such problems earlier.
feline, please tell whether I should test something else, I wait your answer before switching back to 1418. (I can test that hanging VS2005B2 with that version too after the change.) |
|
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Sep 13 2005 : 4:32:31 PM
|
your explanation for why this is slow makes perfect sense to me. i have just loaded one of my small C++ projects to see what happens.
when changing from one file to another there is a slight delay before VA catches up and applies its syntax highlighting to the file.
using winXP pro, VS 2003 and VA 1422 when i use the mouse to trigger IDE menu window -> "close all documents" all open tabs simply close instantly. there is no screen redraw as it moves through each open tab in turn.
are you seeing each tab (file) in turn flash up in front of you as the IDE closes all of the files? i have the IDE set to use tabs rather than MDI mode, which mode are you using?
it is possible this is related to the size of the solution. i have just added Qt 3 to a small solution as a second project, so the solution now contains 2 projects and around 800 code files. i have opened 37 code files in the IDE plus the start page.
close and reload the IDE to help flush any memory VA has of these files, and use window -> close all documents. again all of the tabs simply close instantly. there is no intermediate screen redraw, one moment i have code and lots of tabs, and the next instant the whole area is simply a dark blue rectangle.
how does this compare with your experience? it seems there is some basic difference here, it is a case of finding what and why.
as for VS 2005 beta 2 handing, i have tried this two different ways. first i loaded a local managed C++ project in VS 2005 beta 2, and then loaded a second IDE just fine.
next i closed both IDE's and opened a sort of network C# project (VMWare "network" drive, a share from the host OS) and again i can open a second IDE just fine.
this is using VA 1422 on win2k. |
zen is the art of being at one with the two'ness |
|
|
|
jmihalicza
Ketchup Master
Hungary
66 Posts |
Posted - Sep 14 2005 : 05:24:53 AM
|
I tried sg: without solution both open and close are fast. I don't even see the redraws. (I am using tabs, no MDI.)
An interesting thing (now with the solution): If I just drop some files to the IDE from a file manager, then the delay at close only applies to those have been ever activated, and sometimes their corresponding .hpp/.cpp pair.
- Drop 6 files, do nothing, close all: 1 delay (the document activated after drop)
- Drop same 6 files, activate other 2: 3 delay, during close they are activated in the IDE one by one, I see their contents.
- OFIW 6 files, no extra activation: 6 delays
In my solution there are five projects of which one is 10 times bigger than the others.
I opened an empty solution, added the small projects to it one by one. Before adding the big one everything went ok, though in one case I experienced some delay, but couldn't reproduce (tried all those activation things). I just noticed that the open also got slower and slower.
Finally added the big project. That's it. Open is a bit slow, but usable, but close is terrible. Unfortunately I almost always have to work on that big project.
I did everything on the local source/projects/solution, no network access.
Some statistics (grep "RelativePath" x.vcproj | wc -l)
smallproject1 : 606
smallproject2 : 314
smallproject3 : 683
smallproject4 : 504
bigproject : 7009
The solution (now with the bigproject included) is opened in the IDE, second IDE hangs at startup (no redraws, full white).
Closed solution, no save, second IDE starts immediately.
Opened the existing solution (has the same contents), second IDE doesn't respond, but redraws, is not full white.
Disabled VA, open/close remained slow, disabled in add-in manager, closed IDE, started IDE: VA options menu item remained active, but does nothing, VA enable/disable menu item active, but does nothing.
In add-in mgr Startup check box next to VA is somehow checked in (it was not me, I checked it off before quit, I don'tknow why it is on).
Second IDE starts quickly.
Opened solution, opened some files, activation, anything, no delay at all.
Second IDE starts quickly.
Enabled VA in add-in mgr, close IDE, start IDE, close is slow.
Second IDE starts quickly.
Closed second IDE.
opened some files, activate, everything, open and close is like lightning.
I don't know what happens, VA is on, syntax highlight, ALT+G, OFIW works.
Closed solution, opened same solution, it is slow again, with the very same files, also open seems substantially slower than right before.
Opened some files using solution explorer (multiselect + Enter, dbl.click), it is fast again. Hey man, I got the workaround  .
Let's play!
Closed solution, opened same solution.
Opened 4 files using OFIW. slow open, terrible close.
Dbl. click in sol.explorer to open a file, close all, open same 4 files with OFIW, same slow.
multiselect in sol.explorer, opened 6-7 files, close all, quite fast, 'coz no activation, open same 4 files with OFIW, same slow.
The workaround doesn't always work .
When the close is slow and the last file disappears (IDE window gets dark gray), then the save button remains active for a time, it is probably the delay of the last file.
Opened a single file from sol.exp. to see this delay with the last file again, but it was fast. It is fast with more files again. What happens? Opened same 4 files with OFIW, fast open, lightning fast close.
Well, that's it for now, I hope these can help solving the problem, now that I see I can enable speed somehow with sol.expl. (otherwise I don't use it at all, it is on auto hide, I always use OFIW) I won't go back to 1418 (though coloring was better, but big hopes for 1423). |
|
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Sep 14 2005 : 5:00:18 PM
|
right, lets make a larger test solution. using VS 2003 i have setup 3 projects in one solution:
fileSelect = 8 files
qt 3 = 791 files
firefox = 8012 files
load the IDE and open this solution. using a file manager i dragged 15 cpp files from the firefox project into the IDE, and then select "close all documents". it is instant.
am i missing something obvious here, or is this basically what you are doing?
i am trying various different combinations of opening files, using drag and drop, or the IDE's solution explorer, or VA's OFIW. so far no delays at all. the only slow thing is expanding a folder with 4000 files in it in the IDE's solution explorer.
i thought you had slow close in VS 2003 and the IDE locking up problems in VS 2005. it is not clear which version of the IDE you are using for which test in your post. |
zen is the art of being at one with the two'ness |
|
|
|
jmihalicza
Ketchup Master
Hungary
66 Posts |
Posted - Sep 14 2005 : 8:44:40 PM
|
The tests were made using VS2005b2. Once I've tried with VS2003 to check whether it is only in 2005 or not. VS2003 was the same.
I've put together a test project containing ~3000 files from the firefox source, only one project. The computer is not the same, IDE is VS2003.
The slow close effect appeared for the first test. After some similar tests it became fast.
I tried to play with close/open solution, and immediately after open it always seemed slow but suddenly got fast.
Consider the following results:
* > 8000 files, networked access: it is always slow
* > 8000 files, local: it is slow, but with some clicks it gets fast after a while
* ~ 3000 files, local: it is slow after adding thousands of files to the project, and right after opening solution, but gets fast shortly after open
All these leads to the consequence that it is the initial parsing phase that makes close slow. There was no workaround, but rather the end of the parsing process in the background. With this smaller solution I was hardly able to reproduce the effect due to the shorter time of parsing.
Unfortunately the network access is much slower than local that means I have to wait a lot (probably more hours).
Another problem is that our project files are generated by a script. Each time I want to see the newly added files in the OFIW window I have to reload the newly generated project that means a new parse process in the background. Sometimes I remove or add some projects from/to the solution -> parsing again.
I have never experienced this problem before with the same hw/sw/project configuration, I hope it will be possible to fix this drawback of the renewed parsing. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Sep 15 2005 : 6:29:30 PM
|
good details, thank you for this. i will ask and see what support make of this.
when you get VS 2005 to hang, is this only with with the large project? does this work if the large project is local?
i have just been attempting to make VS 205 beta 2 convert my 8000 file project, but it is not happening, so it will take me a little while to setup a test for this problem. |
zen is the art of being at one with the two'ness |
|
|
|
jmihalicza
Ketchup Master
Hungary
66 Posts |
Posted - Sep 15 2005 : 8:05:52 PM
|
The VS2005b2 hang can be reproduced without network access.
I have a solution containing 8 source files in 3 projects, but they include boost headers.
1. launched IDE
2. opened this solution
3. launched another IDE
The second IDE seemed to hang, but I waited. The HDD was working quite hard, then after quite a long time it stopped, and the IDE became responsive.
This was a solution with 8 source files taking ~1 min for the 2nd IDE to load (this is another computer, 1.7 Intel Centrino, 512MB RAM). Probably I should have waited a bit more for the 2nd IDE when the first IDE contained 8000 files.
It's interesting that next time everything went smoothly, I couldn't reproduce it.
I copied the solution with the sources to another drive, it produced some delay, but was normal.
HTH |
|
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Sep 17 2005 : 5:01:01 PM
|
*considers* this description sounds like the delay could be caused by VA parsing a load of boost headers the first time. i have noticed that when you open a cpp file VA will often start parsing included header files at that time, and not before.
if this is happening for you how it happens for me then the IDE status bar should have been showing you messages about VA's parsing behaviour.
if i email you via the forum would you be able to send me a zip of this small project? i have boost available here, so i can try and reproduce this effect. |
zen is the art of being at one with the two'ness |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Sep 24 2005 : 03:13:16 AM
|
quote:
Originally posted by jmihalicza
All these leads to the consequence that it is the initial parsing phase that makes close slow. There was no workaround, but rather the end of the parsing process in the background. With this smaller solution I was hardly able to reproduce the effect due to the shorter time of parsing.
Unfortunately the network access is much slower than local that means I have to wait a lot (probably more hours).
Another problem is that our project files are generated by a script. Each time I want to see the newly added files in the OFIW window I have to reload the newly generated project that means a new parse process in the background. Sometimes I remove or add some projects from/to the solution -> parsing again.
I have never experienced this problem before with the same hw/sw/project configuration, I hope it will be possible to fix this drawback of the renewed parsing.
In previous builds, VA was blind to the addition and removal of projects to the current solution. Starting around 1422, VA parses those changes.
We need to fix the "parse all headers when opening project" option and expand its use to when projects are added/removed from the current solution [case=755]. |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Sep 28 2005 : 4:32:30 PM
|
| build 1424 has a fix for bug 755 (the failure of "parse all headers when opening project" to be disabled properly) - the opening of large projects will benefit from unchecking that option (on the performance page of the VA options dlg) |
|
|
| |
Topic |
|
|
|
Topic Locked
