Bad performance when exporting as .NET Interop Assembly

[skallen]

I have a complex labview program that can run heavy calculation processes in parallel and have no problem using up most of the CPU-power on my computer (Intel(R) Core(TM) i7-8750H CPU) when running it in labview or as a compiled exe. The calculations finished reasonably fast.

When I try to export my program as an .NET Interop Assembly and then re-import it to labview it also runs at full CPU utilization (and finishes in about the same time), but when I run it from a c# process it looks like it only can use one core/thread, instead of 95% CPU it stays at 15-20%, and takes much longer to finish calculations.

Example:

Is there a special way to load labview assemblies to get the full performance or is there something else one should do to keep the multithread performance when running labview assemblies?

Code for loading and running my assembly:

Assembly lvDll = Assembly.LoadFile("lv_test.dll");
Type test = lvDll.GetType("InteropAssembly.LabVIEWTest");

// Rearm the simulation if the dll as been loaded before
MethodInfo run = lvDll.GetMethod("lv_test_run");

object[] dataParams = new object[] { paramfile, count, seed};

run.Invoke(lvDll, dataParams);

[wiebe@CARYA]

In C#, you don't have the luxury of automatic threading. All code runs in one thread. If you want more threads, you need to explicitly make them.

It seems that the LabVIEW method is simply being executed in the threads it's been given by the call: one.

Parallel for loops won't change this, they divide the clumps between the available threads.

I doubt there are ways around this. In C#, the model is explicit, and in LabVIEW it's all automatic. It just doesn't match.

I've never done this though. There is a small change off different results by using a different method for parallelization, but it seems the model is by design.

[JonoJensen · Accepted solution]

All you need is to set "default" as Pref. execution system on the VI to get full performance.

[wiebe@CARYA]

---

@JonoJensen wrote:

All you need is to set "default" as Pref. execution system on the VI to get full performance.

---

Have you actually tested that? In a VI build in an assembly, called from C#?

I hope it works...

[JonoJensen]

Yes it's been verified.

[wiebe@CARYA]

---

@JonoJensen wrote:

Yes it's been verified.

---

Great. +1 for posting.

[skallen]

Yes, worked like a charm, thanks 🙂

[billko]

---

@JonoJensen wrote:

All you need is to set "default" as Pref. execution system on the VI to get full performance.

---

I was skeptical that it would work, but I also knew that I didn't know enough about it to make a comment, so I waited to see if it worked before I said anything.  Great job!

[wiebe@CARYA]

---

@skallen wrote:

Yes, worked like a charm, thanks 🙂

---

You have a great post / kudo ratio (66%)!

Try to keep it up 😎.

[billko]

I am reminded that when building a dll, you should have the Advanced --> Execute VIs in private execution system checked to make it work as it does in LabVIEW (i.e., multithreaded).

(It sounds suspiciously like an automatic way of doing what was suggested above.)