Debugging extremely slow under 3.2.2

[carsonw]

I'm having troubles debugging under 3.2.2 - I did not have any troubles under 3.2.1.

While stepping over, into etc. the my entire system takes very long pauses. If the test execution is stopped at a breakpoint, I will also experience intermittent pauses (for example if I copy/paste a value into another application, the entire system will freeze for a moment, and then the value will be pasted).

If I try and roll the execution back a few steps and then allow debugging to continue, the performance will degrade even further, and strange behaviour will start to occur - for example, Pressing F10 to step over will cause the File menu to highlight! I can only step over by using the menu shortcuts. If I hover over a string, instead of getting the string value in a nice tooltip I can right click to copy to clipboard, I get the entire contents of the string visible in one giant tooltip and there is no way to interact with it.

I am using Windows 7 Enterprise - 64 bit.

I have also noticed the Ranorex Spy is extremely slow. The 64 bit version is slightly better, but there are still very long pauses (the AUT is 32 bit).

[Support Team]

Hi,

I have tried to reproduce the issue but in my case everything works as fast as in 3.2.1.
Can you send us some more information about your working machine (CPU, RAM, ...) and the used technologies?
Please also send us a Ranorex Snapshot file of your AUT.
We haven't heard about performance issues with the new 3.2.2, so we would need as much information about your AUT, the circumstances and test environment as possible, because otherwise it will be very hard for us to find a solution for your problem.
After upgrading do you have changing something or updated something else on your working machine, or do you have changed some Ranorex settings?
Are you using multiple debug pads, because these pads slow the debugger down?

The 64 bit version is slightly better, but there are still very long pauses (the AUT is 32 bit).

If your AUT is really 32 bit it couldn't be that the 64 bit Spy is faster, because actually the Spy with the appropriate bit version is always faster than the other one.
As your AUT is a 32 bit one please determine that the Ranorex executable is also a 32 bit one, so open the Compiling settings of your Ranorex project and check if the Target CPU is set to "32-bit Intel-compatible processor".

Regards,
Markus
Ranorex Support Team

[carsonw]

I'm not quite sure what you mean by debug pads? One thing that I could do, if it's helpful, is record a video - it is so slow it's almost unusable

I've emailed in a snapshot of the AUT. All executables were set to use 32bit - the DLLS were set to AnyCPU (does it matter for DLLs?), I changed them to 32 bit as well anyway - it did not make a difference.

In terms of my machine, here are the stats:

Windows 7 64 Enterprise Edition
6 gigs of RAM
Intel Core i5 CPU 650 3.2GHz.
Compiling with .NET 4.0

I can roll back to Ranorex 3.2.1 and see if that makes a difference.

*Edit: I rolled back to Ranorex 3.2.1 and I had no problems or delays debugging. I will now roll forward again and confirm the problem has returned!

**Edit: I rolled forward to 3.2.2 and the problem has now resumed. I tried it on a colleague's machine with the same result. I can see the Windows App that's being tested kind of... flash (the fields flash) while I'm stepping through, it's very strange.

It looks like there is some different behaviour between the two version - but I'm not sure what else to look at to help narrow down this problem.

[Support Team]

I'm not quite sure what you mean by debug pads? One thing that I could do, if it's helpful, is record a video - it is so slow it's almost unusable

Yes please record us a video to show us the issue.

Would it be possible to try also the following things?
On the position where you set the break point, could you add a stopwatch functionally to measure the time how long it needs to execute those actions? Just at run time without the break point. If its slower then, we know that this is a core issue and has nothing to do with the Ranorex Debugger.
Stopwatch:
http://msdn.microsoft.com/en-us/library ... watch.aspx

Please try the Stopwatch with both version 3.2.1 and 3.2.2.

Please could you also post us a Ranorex Snapshot of your entire application to see what technology you are using?

Thanks in advance.

Regards,
Peter
Ranorex Team

[carsonw]

Ok, I've recorded the videos and ran the tests with the stop watch. I've email the videos in (hopefully they are not too big, 4.2 and 2.8 megs rar'd) and the snapshot (sent one previously but sent again just to be safe).

Very minor performance difference in terms of execution time around the stopwatch - however I noticed an error under 3.2.2 on the replay window that is not present in 3.2.1. The error does not show up on the report, and I can't see any adverse affect but it is odd it only happens in 3.2.2. The application is exactly the same between versions, I didn't even close I just left it open uninstalled/reinstalled ranorex and went from there.

As a note, on the "slow" video it looks like I am just waiting at a certain step, but I'm actually pressing F10 over and over waiting for it to advance a step.

I did not demonstrate the behaviour where the tooltips start behave strangely (if I right click and select "Set Current Statement") when I move the code execution back during runtime after adding some steps, but I can continue to explore that if it's useful.

Here is the error I encountered only in 3.2.2, and the timing results in general (you will see it in the video):

3.2.1:
[WUWinClients.SPPAdmin.WUSppAdminCustomer+CreditLimts..ctor()] For each in CreditLimts executed in '443' millseconds.
3.2.2:
[WUWinClients.SPPAdmin.WUSppAdminCustomer+CreditLimts..ctor()] For each in CreditLimts executed in '562' millseconds.
Also, this error (in 3.2.2 only):
Getting attribute 'controlname' failed on FlavorElement with flavor 'java'. Index was outside the bounds of the array.

*Edit: I have another colleague reporting the same issue now. However, in her case she is simply sending web service calls, she is not using any windows clients so it seems like it's unrelated to the application itself (in my case I am not sending web service calls and interacting with a windows client directly).
**Edit: I've included two snapshots, one made under Ranorex 3.2.2 and 3.2.1 in case something is being recognized differently causing the error above.

[Support Team]

Hi,

As a note, on the "slow" video it looks like I am just waiting at a certain step, but I'm actually pressing F10 over and over waiting for it to advance a step.

Thank you for the videos and for the snapshot. I was able to reproduce this error and this only occurs if you use the key F10. If you use the Step Over icon of the Ranorex Studio to perform this actions it works as expected. We will fix this bug with the next version of Ranorex. Meanwhile please use the icon to step over in debug mode.

Regards,
Peter
Ranorex Team

[carsonw]

Ok, thanks for the update!