Performance issues after converting JScript project to JavaScript in TC 12
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Performance issues after converting JScript project to JavaScript in TC 12
Hello All,
We run a Delphi desktop application and use TestComplete 12 for a series of automated tests using JScript scripts (no keyword tests). I have converted the JScript project to JavaScript and am experiencing (serious) performance issues after the conversion.
Surprisingly, I only needed to change a single line of code for the project to run in JavaScript (so far!):
from: Project.Variables.VariableByName(pStrVariableName) = pObjValue;
to: Project.Variables.$set("VariableByName", pStrVariableName, pObjValue);
The tests in the JavaScript project run fine with no errors but they take at least twice as long to run when compared to the exact ones in JScript. Is there any project setting I need to change?
The performance issue appears to be when comparing (many) fields on the TestedApp, actual value vs expected value.
I changed aqObject.CompareProperty(pStrExpectedVal, cmpEqual, pStrActualVal, false, lmNone) to equal(pStrExpectedVal,pStrActualVal) but this has not made any difference to the performance in JavaScript.
To give an idea of the speed degradation, comparing 33 fields (among some 'if Object.visible' statements and 2 x 2 second delays waiting for forms to load) took about 5 seconds in JScript but about 9 seconds in JavaScript.
Has anybody else experienced any speed issues with converted JavaScript projects in TestComplete 12?
Any help would be greatly appreciated!!!
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am seeing the same issue as well. I am in the process of converting our codebase to JavaScript but our smoketest performance has increased by 20min! I have not been able to find a solution - have you?
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey Blake,
I raised a support case with the the Customer Care Team for this issue. After looking at my project, they acknowledged/confirmed the speed degradation in the converted JavaScript project and advised that there is no solution for it, for now. They may look into it in future releases.
Some areas in JavaScript execute faster than JScript but overall, the JavaScript project works much slower for me. So my project remains in JScript!
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good to know. We made the decision yesterday afternoon not to convert to JavaScript.
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a question:
Are you actually doing the "conversion" of the project (right click on project, select Convert to JavaScript, make code modifications) or are you doing all this conversion manually?
The reason I ask is, if you are doing the conversion using the built in convert function, what does performance look like if you simply port the code over to a new project configured to use JavaScript with non of that conversion? I don't know if it really makes a difference but more of a curiousity thing.
Robert Martin
[Hall of Fame]
Please consider giving a Kudo if I write good stuff
----
Why automate? I do automated testing because there's only so much a human being can do and remain healthy. Sleep is a requirement. So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.
Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Robert,
I did the conversion of the project using right click project and convert to JavaScript method. However, I think the performance issue is with JavaScript engine in TC.
In my project, I did investigate the performance issue (before contacting support) and narrowed it down to data comparisons, actual vs expected. I was using aqObject.CompareProperty(pStrExpectedVal, cmpEqual, pStrActualVal, false, lmNone) for the data comparisons and then changed it to equal(pStrExpectedVal, pStrActualVal) and it made no difference.
To do some base-line comparisons between the JScript and JavaScript engines, I created a for loop with 100 iterations to do:
1) a simple calculation,
2) compare the calculated value with a fixed value
3) output a line with Log.Message() if the comparison failed
It took about twice the time to run in JavaScript than in JScript. Increasing the number of iterations made it worse in JavaScript!
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Huh... very interesting. Well, here's hoping Support/Development at SmartBear corrects this. I like both JavaScript and JScript but it would be nice to keep using JavaScript as that is where the technology development is happening.
Robert Martin
[Hall of Fame]
Please consider giving a Kudo if I write good stuff
----
Why automate? I do automated testing because there's only so much a human being can do and remain healthy. Sleep is a requirement. So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.
Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Definately slower. I sent in a report to SmartBear about this on 9/15/2016. Still no improvements in the latest version 12. Here is an excerpt of results from the report.
AVG time to iterate through 16 XML elements: Jscript 18.6ms, JavaScript 71.6ms, Python 77.9ms
AVG time to make 16 log messages: Jscript 48.4ms, JavaScript 354.2ms, Python 76.5ms
AVG time per log: Jscript 3ms, JavaScript 22.1ms, Python 4.8ms
AVG time to read the XML file into an object: Jscript ~8ms, JavaScript 28ms, Python 43.8ms
I also noticed issues with using TestComplete UserForms with javascript. In addition, Sys.OleObject used to create a DOM object seems to have a lower limit of the number of child elements that can be read as compared to using ActiveXObject with jscript.
We would like to use javascript as it follows a newer ECMAscript standard but will need to stay with jscript until SmartBear makes some improvements in using javascript.
