Debug Slow

[AlexBorelli]

Hi.

I am using the TestComplete version 12.0.122.7 and when I using the debug is very slow, 13 seconds for change a line.

Do you can help-me?

[tristaanogre]

A lot of it depends upon what you are doing within the script code.  In my environment, sometimes it takes a bit for Step Over to return, sometimes it comes back quickly.

Could you post an example of code that is taking the 13 seconds?

[AlexBorelli]

This code that is taking the 6 seconds:

procedure test;
var a, b : string;
begin
  a := a;
  b := b;
  if a = b then
    Log.Message('Equal')
  else
    Log.Error('Error')
end;

  This code that is taking 11 or 13 seconds.

  Aliases.control.CadAlt_Pedido_Venda.Edit14.Keys('[Enter]');
  Aliases.control.CadAlt_Pedido_Venda.Edit1.Keys('31[Enter]');
  Aliases.control.CadAlt_Pedido_Venda.Edit10.Keys('[Enter]');
  Aliases.control.CadAlt_Pedido_Venda.Edit2.Keys('2[Enter]');

  Thanks.

  Alex

[tristaanogre]

The second block of code is executing actions against mapped components.  NameMapping does carry a little bit of overhead in that it needs to find and recognize the mapped component before it can interact with it.  So, before it can execute the Keys method of 

Aliases.control.CadAlt_Pedido_Venda.Edit14

It needs to first find and map it.  So, evaluating a line with that code in the debugger and having the test stop on the line will take a little longer than stopping on a line in your first example.  If you're doing a lot of Extended Find type stuff, that will add even more overhead.

I'll agree that 11-16 seconds is a bit of a time crunch to wait for the debugger to step through code, but given the code you're stepping through, that is within the realm of possibility.  

how to fix it?  See what you can do about optimizing your name mapping.  If you are using Extended Find, map more parent objects in so that TestComplete doesn't have to search as much.  Make sure your properties you are using in your mapping don't carry their own overhead (some properties actually have to execute code on the control to return a value).

I notice you're sending an "Enter" to each edit field. Usually, when I've seen that done, that means there's some sort of event that fires on an edit field after the Enter is pressed.  So, your delay COULD be TestComplete waiting for that event to fire before it moves on to the next line which would then be an artifact of your application undertest and something to work with your developers on to see if that can be optimized.

This is all guesswork, mind you, but generally speaking, this is why the debugger could sometimes seems slow. 

[AlexBorelli]

Why this code that is taking 6 seconds? This code is very simple.

procedure test;
var a, b : string;
begin
  a := a;
  b := b;
  if a = b then
    Log.Message('Equal')
  else
    Log.Error('Error')
end;

Is the problem only in my NameMapping?

Thanks.

[tristaanogre · Accepted solution]

Good question... however, the debugger does need to get values back and such... also, is this running in the middle of a larger project or is it stand alone?  What sort of process/ram/disc do you have going on your machine?  These are all factors in performance. 

I just tried it on my workstation.  I put a breakpoint on the a := a; line. For me, it took 6 seconds to bring me to the editor for the breakpoint.  However, hitting "step over", each step through the test actually went pretty quickly from there on.  Again, there is overhead in the debugger.

One thing you can try that gave me some pretty good results and reduce that overhead...  Under Tools | Options | Log, there's an option there for "show pause log".  If you disable that, the debugger comes back a lot faster because TestComplete no longer needs to actually populate a log to display on screen while you are debugging.

Another bit of overhead to clean up... if you have any Watches added, each of those needs to be evaluated when you hit a breakpoint... even if the function you are working doesn't impact them, they still need to be evaluated.  Disable or remove any unnecessary Watches in your watch list.

[AlexBorelli]

Hello. This is running in the middle of larger project.

If I running in a project stand alone is very fast, equal you said.

What I do for my project stay very fast in debbug?

I disabled  Under Tools | Options | Log, there's an option there for "show pause log", continues to be slow.

Thank You.

[tristaanogre]

Not entirely sure... but If you haven't disabled the Watch List items, that's the next thing I'd do.

other than that, not a whole lot comes to mind.  Keep in mind, this is interpreted code, not compiled code.  So, a breakpoint has to be "interpreted" through the script engine.. the more script code you have, potentially the longer this will take.

Honestly, 11-16 seconds for debugging ain't bad.  I've seen a LOT worse.  My biggest concern would not be the slow performance on debugging but if my performance is slow in execution.

[AlexBorelli · Accepted solution]

Good morning.

The solution was delete the Watch List Items. Magic solution. Now is very fast my debbug.

Thank you Robert Martin, you are fantastic.

Alex Borelli