C++ vs. Java (speed considerations only)

[apalrd]

Originally Posted by wilful

If you don't know already, Labview has MAJOR lag problems, especially with relays. This year, the code that came with Labview for the relays was unusable and we were forced to write our own. This prevented us from competing in most of our matches at the Sacromento regional. So if you are looking for processing speed, don't use labview.

There are two things that are REALLY slow in LabVIEW:

-VI calls through the normal "execution system" when they should be Subroutines or Inlined. The majority of the WPIlib suffers from this problem, unfortunately. The normal execution system is designed for heavily multitasking systems and systems with many concurrent processes. It treats each VI as an independent node in the execution system, unless it is flagged as Subroutine (or Inlined at compile time), which isn't very efficient. When properly written, LabVIEW code is far easier to multitask without much overhead.

-Programmers writing code while thinking procedurally. Thinking functionally is much better in LabVIEW (and even better in Simulink and more hardcore dataflow and modeling languages). That said, I still firmly believe it's better for programmers to know multiple languages and paradigms, as it will help you better choose the correct language and environment for a challenge.

As for C++ vs Java, non-JIT Java code will be slower. For completely personal reasons, I am a fan of purely procedural C programming for embedded systems.

I am also quite unimpressed by the timing jitter I got in LabVIEW. The RT threads are able to hold very tight timing, but at fairly significant CPU expense.