| Author |
 Topic  |
|
|
KirillMueller
Ketchup Master
72 Posts |
 Posted - Dec 14 2005 : 11:09:45 AM
|
I have a struct like this:
template <class A, class B>
struct P {
A a; B b; };
and code like
typedef P<bool, P<int, P<char*, P<double, P<bool, P<........> > > > > > MyType;
MyType T;
(A recent example was nested 26 levels deep.)
Whenever the source file is scrolled to the position of the typedef code or the code that accesses the MyType object (like T.b.b.b.b.a), the CPU starts to spin and the IDE becomes unusable until eventually VA finishes. When the cursor is positioned over the typedef or over the accessing code, it becomes even worse. It is definitely one of VA's threads that uses the CPU time.
Splitting the typedef into two sub-typedefs greatly reduces the required CPU time:
typedef P<double, P<bool, P<........> > > PX;
typedef P<bool, P<int, P<char*, PX> > > MyType;
Does VA employ some kind of exponential-time (or maybe quadratic, cubic, ...) algorithm for parsing deep templates? Why does it work better when deep templates are split? Is there a chance that this will get fixed in the near future?
Thank you in advance. |
|
|
KirillMueller
Ketchup Master
72 Posts |
Posted - Dec 14 2005 : 11:12:52 AM
|
My system:
WinXP Pro SP2
VS.NET 2005
VA_X.dll file version 10.2.1433.0 built 2005.12.09
Licensed to:
VA X: <my license>
VA.NET 7.1:
VAOpsWin.dll version 1.3.3.0
VATE.dll version 1.0.4.2
DevEnv.exe version 7.10.3077.0
msenv.dll version 7.10.3077.0
Font: Courier New 17(Pixels)
Comctl32.dll version 5.82.2900.2180
WindowsNT 5.1 Build 2600 Service Pack 2
Single processor
Platform: Win32
|
 |
|
|
support
Whole Tomato Software
5566 Posts |
|
|
KirillMueller
Ketchup Master
72 Posts |
Posted - Dec 16 2005 : 4:10:56 PM
|
I've upgraded to 1437, please find my current info below.
Well, actually it got better. I've re-tested it with the 26-levels-sample. Still, it uses a lot of CPU time when I position the cursor into the template declaration - the CPU is busy for about five seconds. Good news, just displaying the template declaration doesn't make the CPU spin.
With 1433, the CPU spinned for an "indefinite" time even when the declaration got into view, far longer than one minute - maybe even an endless loop. Since this affected all of VS.NET, making it impossible to work, I usually turned off VA when the problem occured 
Off-topic: Is there a chance to prevent this kind of problem by setting the corresponding thread's priority to somewhat lower than default?
VA_X.dll file version 10.2.1437.0 built 2005.12.10
Licensed to:
VA X: <my license>
VA.NET 7.1:
VAOpsWin.dll version 1.3.3.0
VATE.dll version 1.0.4.2
DevEnv.exe version 7.10.3077.0
msenv.dll version 7.10.3077.0
Font: Courier New 17(Pixels)
Comctl32.dll version 5.82.2900.2180
WindowsNT 5.1 Build 2600 Service Pack 2
Single processor
|
|
|
|
support
Whole Tomato Software
5566 Posts |
|
|
KirillMueller
Ketchup Master
72 Posts |
Posted - Dec 17 2005 : 2:31:18 PM
|
Sorry, the CPU still is heavily used. It seems that now with 1438 the IDE is more responsive when the CPU starts spinning than with 1437 or 1433, but I might be wrong.
To reproduce the problem, please create a header file with the code below. Open the header file in VS.NET 2005. Now move the cursor to the end of the line where P8 is declared and press "Left" repeatedly (once per second or so) to move the caret over the closing angle brackets. You might notice a small increase of CPU usage. Now repeat this procedure with P12, the CPU usage increases significantly. With P14, the CPU is used even more, and the IDE reacts slower. If you try the same with P16, the IDE still is usable but reacts really slow. Imagine what happens with P26...
P16a is a split variant of P16. In my "real" code, the split variant is handled much better, although this doesn't seem to hold for the stripped-down version presented here.
Of course, the int-s can be substituted with arbitrary types of your choice.
I have a single-processor machine with a P4 running at 2.4 GHz.
template <class A, class B>
struct P {
A a;
B b;
};
struct NIL {};
typedef P<int, P<int, P<int, P<int, P<int, P<int, P<int, P<int,
NIL> > > > > > > > P8;
typedef P<int, P<int, P<int, P<int, P<int, P<int, P<int, P<int,
P<int, NIL> > > > > > > > > P9;
typedef P<int, P<int, P<int, P<int, P<int, P<int, P<int, P<int,
P<int, P<int, NIL> > > > > > > > > > P10;
typedef P<int, P<int, P<int, P<int, P<int, P<int, P<int, P<int,
P<int, P<int, P<int, NIL> > > > > > > > > > > P11;
typedef P<int, P<int, P<int, P<int, P<int, P<int, P<int, P<int,
P<int, P<int, P<int, P<int, NIL> > > > > > > > > > > > P12;
typedef P<int, P<int, P<int, P<int, P<int, P<int, P<int, P<int,
P<int, P<int, P<int, P<int, P<int, NIL> > > > > > > > > > > > > P13;
typedef P<int, P<int, P<int, P<int, P<int, P<int, P<int, P<int,
P<int, P<int, P<int, P<int, P<int, P<int, NIL> > > > > > > > > > > > > > P14;
typedef P<int, P<int, P<int, P<int, P<int, P<int, P<int, P<int,
P<int, P<int, P<int, P<int, P<int, P<int, P<int, NIL> > > > > > > > > > > > > > > P15;
typedef P<int, P<int, P<int, P<int, P<int, P<int, P<int, P<int,
P<int, P<int, P<int, P<int, P<int, P<int, P<int, P<int, NIL> > > > > > > > > > > > > > > > P16;
typedef P<int, P<int, P<int, P<int, P<int, P<int, P<int, P<int,
P8> > > > > > > > P16a;
(I have wrapped the code so that it fits horizontally. The problem seems to get worse when the code is not wrapped so that one declaration occupies one line only.) |
Edited by - KirillMueller on Dec 17 2005 2:38:29 PM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - Dec 18 2005 : 2:38:32 PM
|
confirmed. thankyou for the good example, this made it much easier to reproduce this.
case=929 |
zen is the art of being at one with the two'ness |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Jan 19 2006 : 12:39:37 AM
|
| Fixed in 1440. |
|
|
| |
Topic |
|
|
|
Deeply nested templates use a lot of CPU time
