Rope handling performance at Uniface

One thing every developer struggles with (or should!) Is performance. It’s okay to write an application that works well for a developer who is playing on a development server that only he is using, but it is very different when thousands of users access the same server, under realistic but heavy load.

One particularly expensive task is string handling. Creating a chain can use a relatively large amount of memory and a surprising amount of processor power. So I decided to run some performance tests to see how it could be improved.

The first test I did was to compare the use of a local variable with a field that does not belong to the database. I did this test by taking the following string …

“ABCDEFGHIJKLMNOPQRSTUVWXYZ 01234567890 abcdefghijklmnopqrstuvwxyz 01234567890”

… and then using putitem / id with a counter to add this 20,000 times, with the following results …

Non-database field = 02: 42.14, 02: 44.64, 02: 43.44 (almost 3 minutes).

Local variable = 00: 00.22, 00: 00.23, 00: 00.22 (less than 1 second).

Component variable = 00: 00.22, 00: 00.22, 00: 00.22 (less than 1 second).

Global variable = 00: 00.22, 00: 00.22, 00: 00.23 (less than 1 second.

As you can see, when manipulating a string, you should never use a field to contain the string. Having said that, it doesn’t seem to make any difference which type of variable you use. I kept testing the different types of variables with 200,000 and 2,000,000 iterations, not seeing the times deviate from each other.

Now that I found out that using a variable was much faster than using a field, I’m going to look at the different ways to construct the string. I can only think of two different ways …

Concatenation (using $ concat)

Indirection (eg, “%% string1 %% string2 %%%”)

So I tested them with the following four strings …

“ABCDEFGHIJKLMNOPQRSTU VWXYZ”

“01234567890”

“ABCDEFGHIJKLMNOPQRSTU VWXYZ”

“01234567890”

… keeping the value in a local variable and iterating 20,000,000 times …

Concatenation = 01: 03.08, 01: 03.71, 01: 03.t64 (just over 1 minute)

Indirection = 01: 02.01, 01: 01.74, 01: 01.98 (just over 1 minute)

The difference is almost negligible, as I had to go through many iterations before it could be detected. However, the indirection makes concatenation of seeds to the post, by a hair.

So I decided to try building a larger chain, starting with the first chain and adding the other three, then taking that chain and adding the other three again, and so on. This time I also used a local variable but iterating only 20,000 times …

Concatenation = 00: 56.41, 00: 56.02, 00: 56.37 (just under 1 minute)

Indirection = 00: 55.61, 00: 56.96, 00: 56.92 (just under 1 minute)

Again, the difference is pretty negligible, which shows that size doesn’t really matter in this case.