Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 Deeply nested templates use a lot of CPU time

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
KirillMueller 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.
7   L A T E S T    R E P L I E S    (Newest First)
support Posted - Jan 19 2006 : 12:39:37 AM
Fixed in 1440.
feline Posted - Dec 18 2005 : 2:38:32 PM
confirmed. thankyou for the good example, this made it much easier to reproduce this.

case=929
KirillMueller 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.)
support Posted - Dec 17 2005 : 12:20:23 PM
Build 1438 addresses a problem related to deeply nested templates.

Can you confirm the build helps you?

http://www.wholetomato.com/downloads/VA_X_Setup1438.exe
KirillMueller 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 Posted - Dec 15 2005 : 11:12:21 AM
Before we dig into the problem, do you mind testing build 1437? While not specific to your problem, the build includes this fix:
CPU no longer spins when parsing certain constructs.

http://www.wholetomato.com/downloads/VA_X_Setup1437.exe
KirillMueller 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

© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000