2102a543d1
Jackson is a very heavy library; it supports loads of features that we don't need, and historically has caused issues due to long class loading times (a little over 2 seconds to load AprilTagFieldLayout). This often manifests as a help request in the form of "my robot disables when I do X, but doesn't disable when doing X in subsequent attempts until code restart." While SC has brought down Jackson loading times significantly, with AprilTagFieldLayout loads taking only 330 milliseconds, that's still a rather long delay, and while libraries should handle any JSON loading ahead of time to prevent delays in auto/teleop, it would still be good to make the worst case better to reduce user frustration. Benchmarks indicate using [Avaje Jsonb](https://github.com/avaje/avaje-jsonb) to load AprilTagFieldLayout only takes ~70 ms, a fair chunk of which isn't actually in Avaje Jsonb (~4 ms is spent on using getResourceAsStream to retrieve the JSON file, ~8 ms is spent on just loading the AprilTag class and its dependencies). Note that all times listed are end-to-end, meaning nothing else was done except for the operation being benchmarked, and doing arithmetic on them can be flawed due to some classes being loaded twice, i.e., getResourceAsStream and `new AprilTag()` likely load some of the same JDK classes and so subtracting both from the Avaje Jsonb load time is likely slightly incorrect because class loading is being double counted. For our purposes, it's likely accurate enough and is mostly just for contextualization. Benchmarks were run on a Raspberry Pi CM5 with 2 GB of RAM. Source code for the [results](https://github.com/user-attachments/files/26471452/benchmark.txt) can be found in the "Fastjson2" commit (2456d15ca8ebd17635e607cd40bf8816e77869a1). Avaje Jsonb uses code generation via annotation processors to generate the classes needed to do JSON serde and uses service providers to find them, which will require downstream changes in robot projects, as the different service providers in each library must be merged together for Avaje Jsonb to function. We will use the Gradle shadow plugin, as its already used by the installer and therefore adds zero additional dependencies.
Benchmark
This is a benchmark project built directly against this repo's sources.
Desktop benchmarking
This command runs the Java benchmarks on desktop.
./gradlew benchmark:run
This command runs the C++ benchmarks on desktop.
./gradlew benchmark:runCpp
Deploy to a roboRIO
This project can only deploy over USB. If an alternate IP address is preferred, the address block in benchmark/build.gradle can be changed to point to another address.
This command deploys the C++ project using shared dependencies. Prefer this one for most C++ development.
./gradlew benchmark:deployShared
This command deploys the C++ project with all dependencies statically linked.
./gradlew benchmark:deployStatic
This command deploys the Java project and all required dependencies. It also installs the JRE if it's not currently installed.
./gradlew benchmark:deployJava
Those commands won't start the robot executable, so you have to manually ssh in and start it. The following command will do that.
ssh lvuser@172.22.11.2 frcRunRobot.sh
Console log prints will appear in the terminal.
Deploying any of these to the roboRIO will disable the current startup project until it is redeployed.
Faster builds
If your benchmarks only need some projects, you can comment out or delete unnecessary subprojects from the dependencies, benchmarkCpp, and benchmarkCppStatic blocks in benchmark/build.gradle (Java or C++) and from target_link_libraries() in benchmark/CMakeLists.txt (C++ only).