| T O P I C R E V I E W |
| thruska |
Posted - Mar 08 2007 : 02:25:31 AM
When VAX is enabled, it becomes fairly sluggish to make changes to my base coding library. The .cpp file is 1.4MB in size and the .h file is 200K. These two files get used in all my projects.
Running VAX 1548, but I've noticed it being pretty slow before.
I realize that the .cpp file is huge. It takes 5 minutes for VC++ to build a release mode build of just this one .cpp file. I put everything common'ish in one file because it is just easier to work with. But the VAX slowdown, while still relatively usable, is only going to get worse as I expand this file even more. I can't stand multiple files - it gets too messy trying to remember where each class is located.
My guess is that it has to do with syntax highlighting. Crimson Editor has a similar slowdown problem on large files. Maybe you could offer an option to just syntax highlight anything in the current class and draw black text otherwise in large files (anything over 250K is probably a large file). That would significantly reduce processing overhead. |
| 30 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Sep 22 2008 : 10:40:07 AM
Excellent news  |
| JCo |
Posted - Sep 22 2008 : 08:17:48 AM
Hi feline,
I am happy to report that build 1649 seems to have fixed my problem. Keep up the good work. |
| support |
Posted - Sep 13 2008 : 01:19:22 AM
case=6562 and case=5444 were fixed back in build 1561.
case=6726 addresses giving priority to project include directories over project source directories when locating include files.
case=6726 is fixed in build 1649 |
| feline |
Posted - Aug 14 2008 : 09:56:14 AM
There is a known problem when typing inside very large files with VA enabled. This is a separate problem to the problem with scanning a large number of #include lines.
My large test file is only 23,000 lines long, so 95,000 lines is a slightly scary thought. For now you need to temporarily disable VA while editing files this large. |
| Maxim |
Posted - Aug 14 2008 : 06:45:25 AM
I had to type
#define INVALID_FILE_ATTRIBUTES 0xffffffff
at the top of the amalgamated sqlite.c (95000 lines, see sqlite.org) and it was not a pleasant experience (CPU spikes immediately after every keystroke). I guess it's the same issue as is being covered here but I thought it'd be worth mentioning. |
| feline |
Posted - Aug 13 2008 : 2:43:59 PM
I have the files, thank you for these. I have now found the problem, my test project was not setup quite right, which is why I was getting different results.
I have re-opened:
case=6726
Hopefully having a clear test for this will help  |
| JCo |
Posted - Aug 13 2008 : 04:56:00 AM
Hi feline,
I have sent the requested information to [email protected]. |
| feline |
Posted - Aug 12 2008 : 11:55:01 AM
Something very strange is going on here. I am getting the opposite results to you.
I have tried making the same changes to the test project here, I now have classes CL1 -> CL9.
With VA 1640 I get 13 "PATH NOT FOUND" lines in FileMon.
With VA 1647 I get 3 "PATH NOT FOUND" lines in FileMon.
Which OS are you using?
Can you please send me your current test project, the one with the CL9 class in it. Can you also please export your VA and IDE settings and send them to me:
VA Options -> Performance -> Export Settings
For the VC6 settings can you run regedit and export the registry key:
HKEY_CURRENT_USER\\Software\\Microsoft\\DevStudio\\6.0\
along with all of its children. I will them import your settings here, and use the same project, and see if I can get the same result. |
| JCo |
Posted - Aug 12 2008 : 06:40:52 AM
Hi feline,
I have tested older builds and I can confirm that this problem was (re-)introduced with build 1645.
A test with build 1640 and filemon showed the following result:
12:29:11.428 MSDEV.EXE:3592 QUERY INFORMATION D:\\src\\srcv7.1\\mak\\vaxtest\\classes\\cl1.h PATH NOT FOUND Attributes: Error
12:29:11.428 MSDEV.EXE:3592 QUERY INFORMATION D:\\Src\\SrcV7.1\\mak\\vaxtest\\classes\\cl1.h PATH NOT FOUND Attributes: Error
12:29:11.428 MSDEV.EXE:3592 QUERY INFORMATION D:\\src\\srcv7.1\\mak\\vaxtest\\classes\\cl1.h PATH NOT FOUND Attributes: Error
12:29:11.428 MSDEV.EXE:3592 QUERY INFORMATION D:\\src\\srcv7.1\\include\\classes\\cl1.h SUCCESS Attributes: A
12:29:11.428 MSDEV.EXE:3592 OPEN D:\\src\\srcv7.1\\include\\classes\\cl1.h SUCCESS Options: Open Access: Read
This is what I think is OK. I hope that you can fix this since until then I will use 1640 because even on medium sized files the reparse takes several seconds and this basically disables intellisense almost all of the time.
|
| JCo |
Posted - Aug 12 2008 : 03:58:33 AM
Hi feline,
You can see this behaviour with the original vaxtest project. I have just extended the project with some more classes under \\classes to highlight the problem.
Open the project, open vaxtest.cpp and then start filemon and set a filter for cl1.h.
After this press reparse and you should see something like this:
09:27:06.046 MSDEV.EXE:2996 QUERY INFORMATION D:\\mak\\vaxtest\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:27:06.046 MSDEV.EXE:2996 QUERY INFORMATION D:\\mak\\vaxtest\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:27:06.046 MSDEV.EXE:2996 QUERY INFORMATION D:\\mak\\vaxtest\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:27:06.046 MSDEV.EXE:2996 QUERY INFORMATION D:\\mak\\vaxtest\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:27:06.046 MSDEV.EXE:2996 QUERY INFORMATION D:\\classes\\cl9\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:27:06.046 MSDEV.EXE:2996 QUERY INFORMATION D:\\classes\\cl8\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:27:06.046 MSDEV.EXE:2996 QUERY INFORMATION D:\\classes\\cl7\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:27:06.046 MSDEV.EXE:2996 QUERY INFORMATION D:\\classes\\cl6\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:27:06.046 MSDEV.EXE:2996 QUERY INFORMATION D:\\classes\\cl5\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:27:06.046 MSDEV.EXE:2996 QUERY INFORMATION D:\\classes\\cl4\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:27:06.046 MSDEV.EXE:2996 QUERY INFORMATION D:\\classes\\cl3\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:27:06.046 MSDEV.EXE:2996 QUERY INFORMATION D:\\classes\\cl2\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:27:06.046 MSDEV.EXE:2996 QUERY INFORMATION D:\\mak\\atestlib\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:27:06.046 MSDEV.EXE:2996 QUERY INFORMATION D:\\include\\classes\\cl1.h SUCCESS Attributes: A
09:27:06.046 MSDEV.EXE:2996 OPEN D:\\include\\classes\\cl1.h SUCCESS Options: Open Access: Read
09:27:06.046 MSDEV.EXE:2996 QUERY INFORMATION D:\\include\\classes\\cl1.h SUCCESS Attributes: A
09:27:06.046 MSDEV.EXE:2996 CLOSE D:\\include\\classes\\cl1.h SUCCESS
In contrast, if you use #include <classes/cl1.h> and reparse the file it looks like this:
09:30:49.029 MSDEV.EXE:2996 QUERY INFORMATION C:\\Programme\\Microsoft Visual Studio\\VC98\\INCLUDE\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:30:49.029 MSDEV.EXE:2996 QUERY INFORMATION C:\\Programme\\Microsoft Visual Studio\\VC98\\MFC\\INCLUDE\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:30:49.029 MSDEV.EXE:2996 QUERY INFORMATION C:\\Programme\\Microsoft Visual Studio\\VC98\\ATL\\INCLUDE\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:30:49.029 MSDEV.EXE:2996 QUERY INFORMATION D:\\src\\srcv7.1\\include\\classes\\cl1.h SUCCESS Attributes: A
09:30:49.846 MSDEV.EXE:2996 QUERY INFORMATION C:\\Programme\\Microsoft Visual Studio\\VC98\\INCLUDE\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:30:49.846 MSDEV.EXE:2996 QUERY INFORMATION C:\\Programme\\Microsoft Visual Studio\\VC98\\MFC\\INCLUDE\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:30:49.846 MSDEV.EXE:2996 QUERY INFORMATION C:\\Programme\\Microsoft Visual Studio\\VC98\\ATL\\INCLUDE\\classes\\cl1.h PATH NOT FOUND Attributes: Error
09:30:49.846 MSDEV.EXE:2996 QUERY INFORMATION D:\\src\\srcv7.1\\include\\classes\\cl1.h SUCCESS Attributes: A
09:30:49.846 MSDEV.EXE:2996 OPEN D:\\src\\srcv7.1\\include\\classes\\cl1.h SUCCESS Options: Open Access: Read
Now just imagine how the first filemon listing would look like if the atestlib project held source files spread over hundreds of folders.
It would be great if you could change the lookup behaviour for #include to the way the compiler is doing it and make the exhaustive search in all folders known to have source files only if you did not find the include file before.
If that is too hard to do please consider changing the order for #include G?cl1.hG? to: 1: the folder of the source where the #include is made from. 2: The folders that are configured in the G?additional include foldersG? setting in the workspace. 3: MS specific includes. 4: Folder named G?includeG?. 5: All directories with source files in the workspace.
|
| feline |
Posted - Aug 11 2008 : 12:35:58 PM
Personally I do not actually know the rules VA follows for the order to check directories, but case=6726 has the following description:
quote:
In very large workspaces, we can take a significant amount of time to locate includes. We need to give priority to project specified include dirs (over project source dirs).
and this is listed as fixed in VA 1556. By using FileMon can we show that this is broken using one of your two test projects?
It certainly sounds like it is broken. It would be nice to have a fairly small, simple test to run to confirm the problem and the fix. |
| JCo |
Posted - Aug 11 2008 : 05:49:26 AM
Hi feline,
I performed some additional tests and this is what I have seen (VAX build 1646 and VC6 SP6).
I just tested with various settings of the vaxtest project for include folders and their order. At some point I even removed all settings for include folders and was surprised to see that VAX still found them while VC did not compile anymore. When I named my include folder jnclude and configured this in MSDEV VC compiled OK but VAX did not find the headers anymore.
I always cleaned the VAX cache prior to making a test with a new setting.
I assume VAX works as follows (regarding includes):
- VAX ignores the include settings in MSDEV G?? Extras G?? Options.
- The G?additional include foldersG? setting in the project is evaluated.
- The search order for #include <cl1.h> is: 1: MS specific includes. 2: Folder named G?includeG?. 3: All directories with source files in the workspace. 4: The folders that are configured in the G?additional include foldersG? setting in the workspace.
- The search order for #include G?cl1.hG? is: 1: All directories with source files in the workspace. 2: The folders that are configured in the G?additional include foldersG? setting in the workspace. 3: MS specific includes. 4: Folder named G?includeG?.
My problem is that in this particular workspace a lot of projects are included so that I am able to use Alt-G to go to the source of every method in the library that the active project in the workspace is using.
Since our coding style uses #include G?<filename>.hG? to include files referring code from this library and #include <ostream.h> for system includes VAX ends up to search for one of the headers included with #include G?x.hG? in approximately 700 different directories before finding it, which slows down parsing.
It is not something that keeps me from working but some of the files I am working with have a lot of includes and VAX can take several seconds to parse them and during parsing all of the intellisense is not available.
Is there any way of working around this other than to change all includes to #include <>? It would probably help if the delay from the G?stop editingG? to the reparse could be configured so that the parsing does not happen as frequently as it is just now.
|
| JCo |
Posted - Aug 09 2008 : 05:30:00 AM
Hi feline,
Thanks for the prompt reply.
I was referring to vaxtest.zip, sorry for not making this clear.
I am a little confused: I made my tests with VAX 1646 and 1647 and have seen in both cases that VAX searched for cl1.h in all the \\classes\\cl1...3 folders before looking up the source directory and the include directories. I will do some additional tests when I am back at work and post the results.
|
| feline |
Posted - Aug 08 2008 : 2:14:51 PM
I may be running the wrong test in the wrong file here. From case=6611 I have found 2 test projects, "vaxtest.zip" and "vaxtest2.zip" both for VC6.
"vaxtest.zip" is based around using FileMon to look for "cl1.h" while re-parsing the file vaxtest.cpp
Using VA 1626 when I do this - reparsing the file, using the workspace in its default state (I have not made any changes since extracting it from the zip file) I get 7 "PATH NOT FOUND" errors from FileMon and 7 "SUCCESS", so 14 entries in total.
On the same machine when I use VA 1647 I get 3 "PATH NOT FOUND" errors from FileMon and 7 "SUCCESS", so 10 entries in total.
So VA 1647 appears to be a clear improvement over 1626.
"vaxtest2.zip" is based around sitting at the bottom of a very long file and triggering a listbox. I am seeing the same pattern, for me VA 1647 is faster and "better" than VA 1626.
Here the reparse times for this large file, as monitored by the CPU jumping to 100% are shorter than in VA 1626 and seem a little less frequent.
Do you remember the version of VA you were using before 1646?
Are either of these the correct project to have been testing in? |
| JCo |
Posted - Aug 07 2008 : 11:24:19 AM
Hi,
It seems that the problem with the excessive lookup of include files has returned in one of the current builds (I have tested it with builds 1646 and 1647).
The thing that puzzles me is that it is not depending anymore on the presence on a header file in the project itself.
A solution I work fairly often with gets VA to lookup every include file in hundreds of wrong directories before finally finding it.
This makes VAG??s parsing very slow, it takes several seconds even for smaller files if there are enough includes present.
I could reproduce this behaviour with the same test project I sent you last time (May 22 2007) so I hope you can locate the issue without too much of a hassle.
|
| support |
Posted - Jul 07 2007 : 12:53:04 AM
case=6941, while not on the "fixed" list, is improved in Build 1559 |
| sean |
Posted - Jun 29 2007 : 02:38:46 AM
Yes, the mshtml namespace is huge. Another workaround for this slowdown is to disable the "Show completion list after a character is typed" option (Tools|Options|Text Editor|C#|Intellisense). (And enable VA suggestions.) |
| feline |
Posted - Jun 05 2007 : 1:16:18 PM
Yes, this using statement seems to be key to the problem. When I add this I am seeing the same problem as you, I start typing a line of code and nothing happens, the text only shows up "later":
case=6941
Hopefully commenting out this using statement is an acceptable work around for now. |
| znelson |
Posted - Jun 04 2007 : 2:04:23 PM
The biggest problem for me is getting started on a new line of code. When I start typing an if statement with VA on getting 'if (' typed and on the screen takes 4 - 5 seconds where as w/o VA on it take 1/2 - 1 second. There's definitely a slight delay regardless of whether VA is on or off. Another example is if I start off typing 'this.', getting that takes 4 - 5 seconds but once the context menu is up generally things go quickly.
I disabled VA via the registry setting and didn't see much difference in scrolling speeds. Even with VA on scrolling generally isn't much of a problem. It may be a tad slower, but not enough to be a problem.
What I'm thinking is that it may have something to do with the vastness of the mshtml namespace. When I remove the using mshtml; statement, and fixup all the broken references to be fully qualified, things speed up significantly. Maybe VA (as well as VS to some degree) are just not playing well with all the declarations in that library? I don't think the unhacked version of the HtmlEditor control has the 'using mshtml;' in it, but the version i have does. Try adding that using statement and see how that affects your performance. |
| feline |
Posted - Jun 04 2007 : 12:11:24 PM
"clever" things, if this applies people normally know it mainly this is C++ where people have done very creative things with macro's, or very complex C++ template code, like the more complex and obscure corners of the Boost library.
Thank you for the link, this will make things a lot easier. I have downloaded the zip and unpacked it.
I started by opening the solution in VS2005, and opening the file "HtmlEditorControl\\HtmlEditorControl.cs"
At the bottom of the class, with all of the regions collapsed, I tried typing in the function:
private void testTypingInTHisFile()
{
String strName;
strName.Clone();
}
When I got as far as "strName.|" the completion listbox appeared very promptly, but typing is very slow. The odd thing is that I am not seeing any major CPU usage, and I am seeing similar speed of typing in both VA 1446 and VA 1557.
Does this sound similar to what you are seeing?
One thing I have already noticed, scrolling this file, a mere 5143 lines long (big, but hardly insanely big) feels slow, even when I disabled VA in VS2005 via its menu option.
As a test I have just stopped VA 1446 from loading at all, using the registry key given here:
http://docs.wholetomato.com?W306
and when I re-load VS2005, load this file, expand the bottom region only and use the up arrow to scroll through the file the scrolling speed feels really slow. But again there is no CPU spike to explain why this should be the case.
I am wondering how much of the problem I am seeing is simply down to the IDE its self not liking a file this big. I should be seeing a bigger difference between these two versions of VAX. Are you in a position to easily open the same project and file that I am using, and see what results you get? |
| znelson |
Posted - Jun 04 2007 : 09:33:30 AM
If you disable VA's enhanced syntax colouring does this make any difference?
No it doesn't make any noticeable difference.
How large, both number of lines and file size, are the problem files? I have a very large C++ test file, but no very large C# files, so I will need to create one.
The one I'm working with now is about 5000 lines and about 1000 more in the *.Designer.cs file... It's an open source wrapper for Microsoft's mshtml control. Another one is the core application logic class that is split over about 10 files each a partial class definition.
Are these files "basic" C#, or are you doing things with templates, or any other "clever" features that might be confusing or slowing down VA's parser?
Parital classes. the third party tool has a bunch of using statements that 'rename' a bunch of the mshtml interfaces to shorter aliased names. We use Generic types all over the place. The mshtml wrapper was written in 1.1 so it doesn't really use generics at all. Other than that, I don't think so, could you give some other examples of 'clever' features?
Out of interest is this one really large and complex class, or do you have several classes in one file?
The mshtml wrapper is one gigantic class. The core application class is pretty large with a short section of 'supporting code' that defines some enums and has some delegate/event args definitions. I'll try moving those to a separate file to see if there's any increase in speed.
In earlier builds of VAX, like back in 1445, I didn't have these performance problems (if that helps). The link to the HtmlEditorControl we're using is http://windowsclient.net/articles/htmleditor.aspx. We've hacked the heck out of it to make it into a full blown editor. But, at least you'll have what we started with and a large sample c# file. Let me know if you need anything else. |
| feline |
Posted - Jun 01 2007 : 4:01:11 PM
If you disable VA's enhanced syntax colouring does this make any difference?
How large, both number of lines and file size, are the problem files? I have a very large C++ test file, but no very large C# files, so I will need to create one.
Are these files "basic" C#, or are you doing things with templates, or any other "clever" features that might be confusing or slowing down VA's parser?
Out of interest is this one really large and complex class, or do you have several classes in one file? |
| znelson |
Posted - Jun 01 2007 : 2:39:47 PM
Hey,
I'm using VAX 1557 with C# and in the last few builds have been having serious problems with the intellisense slowing down with large files. When a file approaches a few thousand lines of code I'll type and there will be a few second delay between each character displaying on the screen. Sometimes it becomes so bad I'm forced to disable VAX so I can get any meaningful work done.
Running a P4 3.40GHz, 2 GB RAM., VS2005
Any ideas?
Thanks,
Zack
VA_X.dll file version 10.3.1557.0 built 2007.05.29
VAOpsWin.dll version 1.3.2.2
VATE.dll version 1.0.5.6
DevEnv.exe version 8.0.50727.42
msenv.dll version 8.0.50727.42
Font: Courier New 13(Pixels)
Comctl32.dll version 6.0.2900.2982
Windows XP 5.1 Build 2600 Service Pack 2
2 processors
|
| support |
Posted - May 31 2007 : 01:14:56 AM
case=6562 implemented in build 1557 |
| feline |
Posted - May 26 2007 : 1:48:29 PM
I have the files and have replied to your email JCo |
| JCo |
Posted - May 26 2007 : 06:24:42 AM
Hello,
I have also seen some strange behaviour of intellisense as mentioned in this post:
http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=6313
To reproduce the problem I have created a test project and mailed it to support.
|
| sean |
Posted - May 22 2007 : 6:58:24 PM
case=6726 |
| JCo |
Posted - May 22 2007 : 09:02:06 AM
Hello feline,
I just sent an email to support with a small zip containing a minimal set of files and a brief description how to reproduce the problem.
I was able to reproduce it with this set of files on two different workstations with two different builds of VAX (1549 and 1555) and hopefully you can also see the problem.
Since I did not have an English version of VC6 available I did my tests with the German version.
|
| feline |
Posted - May 22 2007 : 06:52:43 AM
Removing the directory name from the #include line *might* make a difference to this.
Or changing the project settings, so that the include directory that the file lives in is checked sooner rather than later. If I understand correctly VA is scanning the directories in a well defined order, so moving W drive up the list / order should be possible. |
| JCo |
Posted - May 22 2007 : 05:48:16 AM
Yes, VA finally found the header, and it stops searching after finding it. System header files are OK.
I guess I just found out that the problem is triggered by the way we write our include statements. We write includes referencing files that are part of our solution as e.g. #include G?sfc/splash.hG? to separate them visually from system includes.
I modified the file I was making my tests with to only use #include <G?> and all is well, no matter if there is a *.h in my project or not.
But as soon as I change one include to #include G?G?G? VA is enumerating hundreds of directories to find this include file, but only if the *.h file is present in the project.
Please keep in mind that I am still using VC6, this could make a difference. Anyway, since I found out what is causing the long parsing time, I can easily avoid it.
|
