Processing commands super slow

[missydr]

On Friday, after I was done recording a keyword script, the Processing Commands message was shown for over an hour and still did not create the script. Today, I recorded only a couple clicks but the message showed for over half an hour and did not create the script. I've tried disabling "Search for visible objects first" and disabling "Use extended find when possible" in the Name Mapping options. I've also re-booted the VM machine that TC is on. Nothing is working so far.

[tristaanogre]

It is possible that the "Extended Find" is already checked on a number of objects and TestComplete is getting "lost" in navigating what component belongs to what.

Just as a test to this theory, create a new, empty project and try the same record with those options turned off and see if the problem persists.

[missydr]

That worked but now how do I fix it in my other projects? Is there a way to turn off "Extended Find" over the whole project suite?

[tristaanogre · Accepted solution]

"Turning off extended find" for Mapped Objects that already have it on is not something that TestComplete can do.  Because Extended Find "collapses" the object tree, turning it off for any single mapped object means you need to go in and map those ancestor objects and re-organize your mapping around it.  It does take elbow grease to do it manually... OR, your other option is to delete all your mapped objects and remap them.  Either way, it's going to take work to turn off the object for your mapped objects.

[missydr]

UGH! I guess I got some work to do. Thanks Robert!

[tristaanogre]

Yeah, sorry... I'm actually in the same boat myself.  We've had performance issues in test execution because of our prior extensive use of Extended Find as well as there have been many object identification issues where the wrong objects are being associated with parent objects due to ambiguous "Extended Find" usage.  We still use Extended Find... it is a very useful feature for situations where the page is too dynamic for a static mapping... but we are a lot more circumspect these days.  In the meantime, we have a LOT of objects to remap (deleting and recreating is not an option for us) so, whenever we have time, I am head down with Object Spy and NameMapping open, making changes.

[missydr]

While I've been trying to update the Name Mapping, the issue has made almost everything painfully slow. Running test executions, however, run at normal speed. It's only seems to be slow while I'm updating the Name Mapping,  recording scripts, or just adding a new object or it's children. Robert, is that the same functionality you are seeing while you are updating your name mappings? 

[tristaanogre]

Yes.  Here's why:

When you're running the tests, the first time it goes to find an object, it takes what is found and puts it in a memory cache so that, the next time, it just reads from the cache rather than redoes the search.  However, when editing or updating NEW stuff such as when recording or updating, that cache doesn't exist (only exists in runtime) so everytime it accesses an object, including ALL ancestor objects in the tree, it executes the search.  The more "layers" that are compressed via Extended Find, the more intensive the search and the more processing time needed to find the object.