C++ vs. Java (speed considerations only)

[flameout]

Until this past year (I just graduated this year), I would have agreed with everyone who stated that any of the three should be fast enough.

This year, however, we ran into issues with our code's performance. We were using Java. These issues primarily came from low performance in our IO calls.

Benchmarking some of the sensor-reading code, we found that it normally took about a millisecond to read a gyro. I'm not sure what it is for encoders, or to update a PWM output for a motor controller, but I found this to be quite long. Unfortunately, due to this slow read time, we were unable to do integration on all three gyros, which adversely affected our balancing code.

Although I haven't measured for other sensors, I will have to comment that we had to drop our drivetrain control loop from our desired 200 Hz to 100 Hz (this affected our tuning noticeably). We had to do this for the arm as well. Our code was not written in an inefficient manner -- if you think that I may be incorrect, then please check it out; it's at http://code.google.com/p/frc-team-957-2012/.

I'll put in another note that when I benchmarked CAN performance for Logomotion, I found that I could transmit about 180-200 operations per second (depending on the message), which is far below the theoretical 900+. Although I didn't try sending multiple at once, which I now wish I would've tested, I believe that most of the time spent in a CANJaguar setX() call is actually spent in WPILibJ and/or OS code -- not in waiting for transmission and reception of the CAN message.

Note: We cannot say anything about the efficiency of C++ or LabVIEW, and therefore cannot make the statement that either of the two are any more or less efficient than Java. I am purely trying to point out that the statement "all three should be more than fast enough for FRC use" is false.