Big Performance Degradation in LabVIEW 2012

[AristosQueue (NI)]

---

Intaris wrote:.

Spoiler

BTW, this explains why the DD overhead is observed at EACH level of "Call Parent method".

---

No, it doesn't.  The overheads are different between the CPN and a regular DD node. They may benchmark as similar performance hits, but they are different issues.

---

@Intaris wrote:
Why would it be such a massive change?  Just because we don't allow dynamic loading of classes?  Have I misunderstood how FPGA handles this?  It boils down to knowing "This is the exact set of classes which will be active in this hierarchy, no more, no less" when compiling so that type-checking could be done at compile-time as opposed to at run-time.

Isn't this similar to "finalizing" a hierarchy? or "sealing" or whatever any given language calls it.

---

No. Sealing a class or method is something we could add to the language. We still wouldn't be anywhere near the performance of FPGA that we would get from whole-hierarchy compilation.

When you seal a given override, it means no more overrides below this point. So if you have on your diagram a direct call to that method -- i.e. the wire is of the child class type and it is wired to the method call -- then we could eliminate all the DD overhead. But you would still have overhead when you call into a parent class method that has a nested DD call even though we know where that call will go and even if everywhere in your whole application the function is only ever called with your child class. In FPGA, we can eliminate all the DD overhead everywhere completely (indeed, we're broken if we can't eliminate it entirely). Whole hierarchy compilation on RT and Desktop would let us eliminate in many many more places than just sealing a class or method would, bringing us much closer to FPGA.

[Intaris]

Cool, as always, thanks for the extra information.

I still don't claim to know enough to actually be taking part in these conversations, but I'm always thirsty for information.

[AristosQueue (NI)]

I passed the link to some cRio folks. They may reply. We'll see.

[User002]

I see, however I ran the code on my win 7 machine.

Or perhaps the performance fix is intended for RT's only?

Indeed a FPGA-like low-level compile and run-time referencing from LV would be great to have for performance critical code.

Just make it easier to debug than the FPGA as of today. 🙂

Br,

/Roger

[AristosQueue (NI)]

Debugging FPGA is easy! You write your code, deploy it. If it doesn't work as expected, delete it and write it again from scratch. Eventually, you'll get it right! The process is long, but it isn't *hard*!   🙂

[User002]

Ah, that's the trick. I feel enlightened. Unfortunately it wouldn't work in the socialist dystopia where I'm currently residing.

Though, lucky for you guys over the pond there is the (Military)-Industrial Complex with limitless coffers ready to throw some more dough at you? 

But I digress. AQ, thanks for the response.

Btw, have you started on that 3D Labview yet? 

Br,

/Roger

[AristosQueue (NI)]

Team says it got better in 2015, but still not back to 2011 levels.

[User002]

---

@AristosQueue (NI) wrote:

Team says it got better in 2015, but still not back to 2011 levels.

---

Like, how much? 5-10% "better"?

It would surely be interesting to know what it took to close this CAR?

Br,

/Roger

[AristosQueue (NI)]

As I heard it, it isn't a linear quantity... it varies based on call site and conditions, so there's no way to pin a percentage on it. I didn't work on it myself.

[User002]

---

@AristosQueue (NI) wrote:

As I heard it, it isn't a linear quantity... it varies based on call site and conditions, so there's no way to pin a percentage on it. I didn't work on it myself.

---

Oh, I see, I just had another flash of enlightenment.

So when do you head for academia? 

Br,

/Roger