Forum Discussion

AlexBorelli's avatar
AlexBorelli
Contributor
8 years ago

Debug Slow

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's avatar
    tristaanogre
    8 years ago

    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's avatar
    AlexBorelli
    8 years ago

    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

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    8 years ago

    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's avatar
      AlexBorelli
      Contributor
      8 years ago

      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's avatar
        tristaanogre
        Esteemed Contributor
        8 years ago

        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.