Run-time compiler speed

[mbrown]

I'm converting an old VO (2.5) application to X#. This does a lot of complicated calculations, which involves loading many snippets of source code from a file, and compiling and executing them at run-time. But X# seems much slower than VO, so I have run this test code in VO and X# to compare them, which is typical of the calculations used:

LOCAL calcCode AS STRING
LOCAL cbCalc AS _CODEBLOCK
LOCAL values AS ARRAY
LOCAL count AS DWORD
LOCAL result AS USUAL
calcCode := "(a[1,1] + a[2,1]) * (a[1,2] + a[2,2])"
values := { { 12.34, 56.78 },{ 43.21, 87.65 } }
FOR count := 1 UPTO 1000000
cbCalc := &("{ |a| " + calcCode + " }")
result := Eval(cbCalc, values)
NEXT

In VO this takes 8 seconds to run, in X# (release config) it takes 27 minutes 18 seconds.

Is there anything I can do to speed this up?

[Chris]

Hi Michael,

That's because of the macro compiler, due to the way that .Net works, it can't be as fast as the one in VO. We are trying to make the x# macro compiler faster than the one that you currently use (the vulcan one), but there will always be a limit on how fast it can be.

For speeding up execution of your program in x#/.Net, there are some ways, like possibly caching macros, using s smart/fast parser to evaluate the snippets instead of macro compiling them, scripting might be a solution, too. It all depends on what type of source code is included in the text files, how repetitive it is etc. Can you post one typical sample file with such source code to have a look?

Chris

[robert]

Michael,

To add to what Chris said:
The macro compiler in .Net can also do much more. In VO you can only call clipper calling convention (untyped) functions. In .Net you can call all functions, typed and untyped.

Can you test what the speed is if you move the creating of the codeblock outside of the loop ? I bet it is much faster then. it is the compilation of the macros that is the most expensive.

I found that it usually helps to cache the macros. Create wrapper code around the macro compiler and cache the result (Dictionary of macro string and resulting codeblock).

You can also improve the runtime speed of the codeblock by adding type casts in there, so the compiler can produce better code

calcCode := "( (FLOAT) a[1,1] + (FLOAT) a[2,1]) * ( (FLOAT)a[1,2] + (FLOAT)a[2,2])"

Robert

[mbrown]

Hi Chris,

Thanks for the prompt reply. Unfortunately the files are not simple text files, but the code is embedded within objects, so cannot be read directly. The code varies from basic arithmetic to array manipulation and multiple function calls. Although my test routine runs 1,000,000 times in the loop, in practice the program only evaluates a few hundred code blocks in each run, and the slow speed is only really noticable when running a batch of calculations, so it's not that serious a problem. Do you know when the new libraries might be available?

Michael.

[mbrown]

Hi Robert,

Thanks for the reply. Yes, the compilation takes about 3/4 of the time. During these calculations the code blocks that are evaluated are all different, and the results from them are already cached, but I will look at the possibility of caching the code blocks when running batches of calculations.

Thanks for the tip about type casting, although it is important that we can use the existing files as they are, so there is a limit to what we can do here.

Michael.

[ArneOrtlinghaus]

I have made the same experience: It is necessary to cache the compiled blocks where possible. Rexecution of the compiled blocks has a similar speed as in VO. What is nice on the other hand using X#/Vulcan:
- All functions can be called including the strong typed functions.
- Also many dotnet object methods can be called, as long as no method overload has been used.

Arne

[mbrown]

Hi Arne,

Unfortunately the code blocks are never re-executed during a calculations sequence, so caching would not help. Thanks anyway.

Michael.

[Otto]

Is it an option to use a code generator that takes the txt file and transforms it into a dll?
That way, you only have to compile it once in stead of interprete it on startup or during the sequence.

Generating code, calling the compiler and afterwarts loading the additional dll is quite easy.

It only makes sense if the txt isn't constantly changed.

Regards,
Otto

[mbrown]

Hi Otto,

Thanks for the suggestion, but it's not a txt file, it's much more complicated than that. The actual sequence of calculations is built up dynamically each time the program is run according to various parameters and data items, so would need a new dll each time.

Thanks anyway,
Michael.