Forum Discussion

allenj2020's avatar
allenj2020
Contributor
8 years ago

Improving table checkpoint performance

Hello all,

 

Does anyone have any tips on improving table checkpoint performance?

I have many (200+) table checkpoints for the DevEx grids in our Delphi based desktop application.

It's common for these checks to take 15 to 20 seconds or more, even when I'm only checking a subset of the columns: say, 20 rows and 6 out of 30 columns.  That's a significant percentage of a 1 to 2 minute test.

Application size is around 180 mb in memory, on a Windows 10 system with plenty of extra memory.  I already filter to just the tested application, and the other general TestComplete performance tweaks mentioned in other articles.

 

I'm currently running 11.3, would going to 12 give me any performance improvements?  I have no web or mobile tests, just desktop.

 

Thanks!

Allen

3 Replies

Sort By
  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    8 years ago

    I would be willing to bet that a large part of that 15-20 seconds of the check point is not the actual checking but the object recognition.  You're passing an Aliased object to the check point, if it's not been accessed before in the test, it's not in cache so TestComplete needs to get the object and then pass it into the check point.  If there are delays in having the grid display on screen, the project has an auto-wait time out that defaults to 10 seconds so there will be, at most, 10 seconds simply for object recognition.

     

    So, the best bet here is to see what you can do about tweaking performance in object recognition.  Look to see if there are "extended find" calls in the object mapping tree and, if so, consider mapping more parent components to speed up this process.

     

    I think, generally, you're dealing with the overhead of object recognition.  The best bet beyond that is to not use check points that grab whole tables but make your test more targetted... you changed a piece of data, you know it will add a row to the grid.  Compare the row count before to the row count after.  If it increases, you've verified at least part of the test.  Next, grab the data from the row.  Compare it to what you entered in earlier in the test.  If it matches, you're golden.  No need to compare the whole table if all you need to check is a row or cell or so on.

    • allenj2020's avatar
      allenj2020
      Contributor
      8 years ago

      Hi Robert,

       

      Thanks for the tips.  I already have the full object path mapped and aliased, so I don't see any room for improvement there.

      Just to be sure, I specifically added mapping and alias for the object I'm testing at the moment, which is about 18 objects deep in the tree, but didn't see any performance improvement.

       

      I do have some procedures already coded to validate individual grid cells and rows, I'll play around with those and see what the performance difference is.

       

      Allen

      • allenj2020's avatar
        allenj2020
        Contributor
        8 years ago

        And the results are:

         

        Validating an individual cell by getting [Grid].wValue takes half a second (0.468).

        Attempting to loop through the grid by rows or columns appears to scale linearly: 

        Looping through 38 columns on a specified row searching for two specified column+value pairs takes 19 seconds.

        Looping through rows on a specified column to find a specific row by value takes 2.2 seconds to find the match on row 5.

        And as I said before, a Table check against the entire grid takes around 21 seconds.

         

        I had hoped there would be some optimized way to grab and compare an entire specified row, but it looks like there's no such thing as a free lunch.  If I want performance, I have to check against a small set of known column+row values.

         

        Thanks.

        Allen