VO vs X# performance

[baramuse]

Hi all,

I'd like to know if anyone already compared app performance with a VO pored app in X#.
Our app is pretty big and ou X# porting is almost complete (always some glitches here and there) so we have the VO app running alongside with the X# one (sharing the same data) for a smooth transition.

But now we're using a bit more the X# version, we and our customers felt is was less responding that VO.. sometime even pretty laggy.

So we started putting some performance meters in both VO and X#, and indeed we have an average factor of 3 for most of our checkpoints (takes 3 times the time to get from one checkpoint to another).

It's not a benchmark on a very specific operation, but more a real life benchmark putting checkpoints here and there (data, drawing, constructing... ) and timing in between, knowing that the codebase is the same, ported via VOXPorter + some fixes for x#.

Also, now it's ported an "stable" maybe we should start optimizing.
Is there some material/talks/recommend reads about that ?

Regards !

[Chris]

One thing for certain is that for many reasons dbf operations are slower in X# than in VO, so this could be your bottleneck. But before offering optimization advice, you need to first evaluate which exact areas are slower in X# in your particular system.

[baramuse]

One thing for certain is that for many reasons dbf operations are slower in X# than in VO, so this could be your bottleneck.

Do you have any idea how slower ?
A lot of our customers are on ADS, shouldn't be quite the same as most of the work is done on the server side ?
Is is proportional/exponential to the database size ?
Or maybe if we're using too many index or composite indexes ?

But before offering optimisation advice, you need to first evaluate which exact areas are slower in X# in your particular system.

Yes we're going to dig deeper and that's why in that regard I was asking for some general leads to looking into first.

For example, is using usual (thus "boxing/unboxing") takes a toll ?
We can't use the typed sdk (or can we ?) because we're using BBrowser in a lot of places and can't replace it easily

Also using a lot of macros, is the macrocompiler slow ?

I know it's a big/vague question, I'm trying to find leads before drowning

[robert]

Basile,
ADS should be almost as fast in both VO and X#.
The handling of the indexes is done by the server and not by the client.
The macro compiler could be a bit slower, but that would not explain the speed difference that you're seeing.
I suspect that your app has a lot of late bound code. You may be able to improve the speed by switching to early bound code.

Robert

[baramuse]

Basile,
ADS should be almost as fast in both VO and X#.
The handling of the indexes is done by the server and not by the client.
The macro compiler could be a bit slower, but that would not explain the speed difference that you're seeing.

Thanks for clearing that

I suspect that your app has a lot of late bound code. You may be able to improve the speed by switching to early bound code.

From my understanding :
- any method using USUAL parameters will generate late bound code
- any method call on a USUAL object will generate late bound code
- any codeblock will generate late bound call
- any other area ?
Is that about right ?

If it is then yes, our code is 99% based on USUAL objects / parameters.
So that's a thing to dig into, especially in loop or frequently called methods

Question based on that :
Is using the "non typed sdk" slower then ?
And from my understanding, I can't use the typed sdk if I'm using bbrowser, yes ?

Regards.

[Chris]

Hi Basile,

Yes, usuals are slower, but we are talking about microseconds, to tell the difference you must be having millions of commands per second... Which is not to say that it can't be the case, but it's not the usual case in most apps. I would say the macro compiler can be a more likely factor. Everything can be optimized to a certain point for your specific case.

About the typed SDK, indeed you can't use that now, if you use bBrowser. But that's the most unlikely cause of slowness anyway.

[VR]

There are tools that help you identity performance problems in dotnet.

Visual Studio has the performance profiling tools: https://learn.microsoft.com/en-us/visua ... /profiling
An alternative are dotTrace and dotMemory from Jetbrains. They are not cheap, but contain some very helpful features and better vizualization. You can even include the recording part of the profilers in your application using a nuget package. This way you can record a trace on any pc that runs your application and then analyze it with dotTrace. https://www.jetbrains.com/profiler/

Analyzing these traces can be overwhelming at the beginning, because interpreting the data is not easy, especially when you use a lot of latebound calls.

There is also a great library for creating perfomance benchmarks for isolated methods. These are usefull if you have identified methods that you want to optimize. You can compare execution speed and memory use of the current and the optimized version. https://benchmarkdotnet.org/

One other thing to look out are string concatenations in loops. These cause lot of pressure for the garbage collector. These can be optimized using StringBuilder. Strings in .net are inmutable.

[robert]

Basile,

From my understanding :
- any method using USUAL parameters will generate late bound code

No that is not correct. This will not generate late bound code, but will generate a method call with usual parameters. If the method is known at compile time (the variable left of the ':' operator has a type known to the compiler) then this will be an early bound call, but the parameters will be "packed" in a USUAL variable when sent to the method

- any method call on a USUAL object will generate late bound code

That is correct

- any codeblock will generate late bound call

No, that is not correct. If the codeblock is a compile time codeblock then the compiler will try to create an early bound call. However if you are calling methods on a parameter of the codeblock then that will be a late bound call, because by default the parameters are usuals.
So this code

Code: Select all

{|oWin|oWin:Show() } 

will generate code that does a late bound call on the Show() method.
However, X# also allows typed parameters in codeblocks

Code: Select all

{|oWin as Window|oWin:Show() } 

In this case the parameter is still a usual, but the compiler will generate code that assigns the usual to a variable of type Window (which will produce a runtime error if the variable has the wrong type) and will then generate a early bound call to the Show() method.

Runtime (Macro compiler) codeblocks will do the same. So this code

Code: Select all

cb := MCompile("{|oWin|oWin:Show() } ")

will produce a code block that does a late bound call to the Show() method.

If it is then yes, our code is 99% based on USUAL objects / parameters.
So that's a thing to dig into, especially in loop or frequently called methods

What you can do is to disable late binding in code that gets called a lot by adding a compiler pragma to the source code.
You can leave late binding on at the project level, but include this pragma line into PRG files with common used code:

Code: Select all

#pragma options("lb", off)

That way you can gradually improve the code.
And if you do not know the type at compile time, you might consider to use the Send(), IVarGet() and IVarPut() functions to work around this and call methods / properties late bound

Is using the "non typed sdk" slower then ?
And from my understanding, I can't use the typed sdk if I'm using bbrowser, yes ?

I suspect that the speed problems are not coming from the code in the VO SDK but from your own code.
So don't bother switching to the typed SDK, unless you have resolved all issues in your own code.

Robert

Regards.

[baramuse]

Thanks a lot for your answers !

I will dig into late bound calls using the pragma.

@VR yes I've used the performance monitor with the memory usage to detect the memory leaks, I'll have another go to try to find the bottlenecks

Fun ahead !


Thanks again.

[wriedmann]

Hi Robert,
may I ask you to put some of your advices in an article on this website?
Or to make a online course and a Youtube video of it?
These things are really important for everyone that migrated applications to X#.
Wolfgang