For those curious Java versus LS. It's lightning fast:
String to char[]: 15ms, string length, 700 000
Added to the string concatenation "benchmark"
Showing posts with label benchmark. Show all posts
Showing posts with label benchmark. Show all posts
Monday, October 15, 2007
String concatenation with a Java agent
Here are the results from string concatenation in Java:
Standard concatenation (75 000 concatenations): 192.594s, string length, 300 000.
java.lang.StringBuffer-concatenation (75 000 concatenations): 0.062s, string length, 300 000.
RTI-concatenation (75000 concatenations): 1.765s, string length, 300 000.
The best in LS, 75 000 concatenations, 0.25s. The numbers aren't directly comparable, as I'm running on different hardware than Julian.
By "Standard" concatenation, I mean bigString += string. Standard concatenation and RT-concatenation is slower in Java than in LS. Using Java's native StringBuffer class, is a lot faster than any of the competitors in LS (so far).
I'm not surprised that Java's StringBuffer beats Julian's array-based StringBuffer-class in LS, as Sun probably puts a lot more effort into optimization of the language than IBM does with LS.
My test ran on Notes 7.02, which I think runs version 1.4 of the Java runtime. Newer versions of Java may be even faster.
My Java-skills are mediocre at best. Let me know if my test-methodology is wrong in any way.
>> Code for the test
Standard concatenation (75 000 concatenations): 192.594s, string length, 300 000.
java.lang.StringBuffer-concatenation (75 000 concatenations): 0.062s, string length, 300 000.
RTI-concatenation (75000 concatenations): 1.765s, string length, 300 000.
The best in LS, 75 000 concatenations, 0.25s. The numbers aren't directly comparable, as I'm running on different hardware than Julian.
By "Standard" concatenation, I mean bigString += string. Standard concatenation and RT-concatenation is slower in Java than in LS. Using Java's native StringBuffer class, is a lot faster than any of the competitors in LS (so far).
I'm not surprised that Java's StringBuffer beats Julian's array-based StringBuffer-class in LS, as Sun probably puts a lot more effort into optimization of the language than IBM does with LS.
My test ran on Notes 7.02, which I think runs version 1.4 of the Java runtime. Newer versions of Java may be even faster.
My Java-skills are mediocre at best. Let me know if my test-methodology is wrong in any way.
>> Code for the test
Sunday, October 14, 2007
Redim performance
Out of curiosity/"challenge" from Julian, I did a little test of ReDim performance.
I'm not that familiar with redimming arrays, so someone let me know if this way of testing is bad.
Result:

Code:

Percentwise, the difference is humongous, but in seconds, not that big of a difference.
>> Code as text
I'm not that familiar with redimming arrays, so someone let me know if this way of testing is bad.
Result:
Code:
Percentwise, the difference is humongous, but in seconds, not that big of a difference.
>> Code as text
Labels:
benchmark,
lotusscript