Ranorex 7.0 performance

[Mikhail]

Hi,
We are working on UI automation testing of large web site.
Now we use Ranorex 6.2.0 version.
Usually we do upgrade to latest version of the automation tool. Before each migration we make estamations of performance and backward compatibility.
We have a very large solution, so even a slight decreasing of performance matters.

There are some estimations:
-------------------------------------------------------
Case 1:
1. open solution (auto update)
2. rebuild solution

Old version (6.2.0):
-open (auto update) 1 min
-rebuild solution 3 min 40 s

New version (7.0):
-open (auto update) 1 min 05 sec
-rebuild solution 6 min 40 sec
-------------------------------------------------------
Case 2:
Running time (time between pressing "Start test case" button and starting execution of test):
1. building time
Old version (6.2.0): 1min 30 sec
New version (7.0): 2 min 20 sec
-------------------------------------------------------
So we see decreasing of performance.

We have already faced with same situation while 5.4.6.-> 6.0 migration.
The problem was described on this topic:
http://www.ranorex.com/forum/viewtopic. ... t=9586&e=0
That time we skipped 6.0 version and migrated to 6.1 version.

Is it known issue about low performance with large solution on latest version ?
We can provide any necessary data if it is needed.

[Support Team]

Hello Mikhail,

We have not had any performance issues reported in the 7.0 release. First, we need to narrow down where the issue lies. I am assuming you tested both versions on the same machine so we can rule out hardware. Have you tried using MSBuild to build/rebuild your solution to see if it is a Ranorex Studio issue, or something in your solution?

Walkthrough: Using MSBuild

Code: Select all

msbuild.exe SolutionName.sln /t:Clean,Build

Do you see the same performance decrease when trying to build (via Build > Build Solution)? Typically, you do not need to rebuild your project each time. Is there a reason you do not use build?

Are you able to send us a copy of your solution so we can try to duplicate on our end ([email protected])? We can provide FTP credentials if it is to large for email.

I hope this helps!

Kind Regards,
Ned

[Mikhail]

Thahks for the answer.

We do not use MSBuild for solution rebuilding.
As I know native Ranorex builder updates auto generated *.cs files based on repository xml file.
We often change repository file so we have to use native Ranorex builder to update auto generated files.

When I get approve from our managers I will send source code of the solution .

[Support Team]

Ranorex uses MSBuild in the background, so if you are using Ranorex Studio to build, you are actually using MSBuild. The goal of using MSBuild outside of Ranorex Studio is to narrow this down to a Ranorex Studio issue, or solution specific issue.

Kind Regards,
Ned

[Stub]

I hit that same issue with the Ranorex Studio generated source code files vs raw MSBuild. In the end I included the generated Repository .cs file(s) in Subversion along with the .rximg and .rxrep files. So I generate then when I use Ranorex Studio, commit those auto-generated changes too, but I can still build the tests with MSBuild when needed. I am working on the assumption that only Ranorex Studio can generate the Repository .cs files.

[krstcs]

Stub, that is correct, only Ranorex Studio can/will regenerate those backing files. MSBuild has no idea how to do that, it's just a compiler. They should be included in your source code versioning system if you are going to use MSBuild. For some reason some of the Ranorex team is suggesting to put them in your ignore file, but I strongly disagree.

As for the performance issues, I can't help since I'm stuck on 6.2.1 due to breaking changes in 7. But I build with MSBuild on my server and the only big difference in time is the code check/generation in Studio. The actual compile is about the same.

[Stub]

When I realised the issue with generating the code generated modules it was obvious, but I sort of hoped there might be a command-line way of regenerating them from the .rxrep. I've not pursued this as I just whapped the generated .cs files into svn to solve the immediate issue.

[Mikhail]

We have added to TFS autogenerated repository *.cs files and we make checkins of these files.
As mentioned above using of MSBuild is inappropriate approach because of updating generated *.cs files.

I think our solution will be shared with support team shortly.

[krstcs]

MSBuild is fine to use if you include the generated files in your code repository.

As Ned stated, MSBuild is how Ranorex builds the solutions. Ranorex Studio will regenerate the files, if they are missing, before using MSBuild.

The point here is that if you will try building the WHOLE solution (including all generated files) with MSBuild, it will help the Ranorex team narrow down what your issue might be.