| Author |
 Topic  |
|
JCo
Senior Member
Germany
40 Posts |
 Posted - May 21 2007 : 07:36:48 AM
|
Yes, the *.rch files really exist, VA should find them in w:\\rc. Please note that it is not only happening for the *.rch files but with every include file.
Seems to me that, as soon as there is an *.h file in the workspace, VA is trying to find every include file in every possible path, even in the directories of all the source files.
I include an (shorted) example, logged with filemon.
MSDEV.EXE QUERY INFORMATION D:\\src\\srcv7.1\\apl\\ger\\sfc\\splash.h NOT FOUND Attributes: Error
MSDEV.EXE QUERY INFORMATION D:\\src\\srcv7.1\\apl\\forecast\\sfc\\splash.h NOT FOUND Attributes: Error
MSDEV.EXE QUERY INFORMATION D:\\src\\srcv7.1\\apl\\envelope\\sfc\\splash.h NOT FOUND Attributes: Error
MSDEV.EXE QUERY INFORMATION D:\\src\\srcv7.1\\apl\\dialoge\\sfc\\splash.h NOT FOUND Attributes: Error
MSDEV.EXE QUERY INFORMATION D:\\src\\srcv7.1\\apl\\commissionexport\\sfc\\splash.h NOT FOUND Attributes: Error
MSDEV.EXE QUERY INFORMATION D:\\src\\srcv7.1\\apl\\PERSON\\sfc\\splash.h NOT FOUND Attributes: Error
MSDEV.EXE QUERY INFORMATION D:\\src\\srcv7.1\\apl\\blob\\sfc\\splash.h NOT FOUND Attributes: Error
The actual include file was sfc/splash.h and this file is located in w:\\include\\sfc. This lookups are done (in this case) for 680 different directories.
If the *.h file is not present in the workspace VA is looking up the file in 6 directories: relative to the directory the referencing source is located, then relative to the workspace (twice), then in the project specific include directories and finally in the MSDEV (global) include directories.
|
 |
|
|
feline
Whole Tomato Software
United Kingdom
18755 Posts |
Posted - May 21 2007 : 11:57:28 AM
|
That makes a degree of sense, since your code is referencing this header file, and VA needs to find it before it can parse it.
Are there any entries in the log showing that VA has successfully found this header?
If VA finds and parses the header, but then keeps looking for it this is a different problem to never finding the header.
This header is found via W drive, are you only seeing this problem for header files that are found on W drive, or are you also seeing it for standard header files? |
zen is the art of being at one with the two'ness |
|
|
|
JCo
Senior Member
Germany
40 Posts |
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.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18755 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
JCo
Senior Member
Germany
40 Posts |
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.
|
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - May 22 2007 : 6:58:24 PM
|
| case=6726 |
|
|
|
JCo
Senior Member
Germany
40 Posts |
|
|
feline
Whole Tomato Software
United Kingdom
18755 Posts |
Posted - May 26 2007 : 1:48:29 PM
|
| I have the files and have replied to your email JCo |
zen is the art of being at one with the two'ness |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - May 31 2007 : 01:14:56 AM
|
| case=6562 implemented in build 1557 |
|
|
|
znelson
New Member
3 Posts |
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
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18755 Posts |
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? |
zen is the art of being at one with the two'ness |
|
|
|
znelson
New Member
3 Posts |
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
Whole Tomato Software
United Kingdom
18755 Posts |
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? |
zen is the art of being at one with the two'ness |
|
|
|
znelson
New Member
3 Posts |
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
Whole Tomato Software
United Kingdom
18755 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
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.) |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Jul 07 2007 : 12:53:04 AM
|
| case=6941, while not on the "fixed" list, is improved in Build 1559 |
|
|
|
JCo
Senior Member
Germany
40 Posts |
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.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18755 Posts |
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? |
zen is the art of being at one with the two'ness |
|
|
|
JCo
Senior Member
Germany
40 Posts |
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.
|
|
|
|
JCo
Senior Member
Germany
40 Posts |
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.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18755 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
JCo
Senior Member
Germany
40 Posts |
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.
|
|
|
|
JCo
Senior Member
Germany
40 Posts |
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.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18755 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
JCo
Senior Member
Germany
40 Posts |
Posted - Aug 13 2008 : 04:56:00 AM
|
Hi feline,
I have sent the requested information to [email protected]. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18755 Posts |
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 |
zen is the art of being at one with the two'ness |
|
|
|
Maxim
Ketchup Master
59 Posts |
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
Whole Tomato Software
United Kingdom
18755 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
support
Whole Tomato Software
5566 Posts |
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 |
|
|
|
Topic |
|
Sluggish on large files.
