Some time ago I worked for a startup company that developed a fitness sensor who used the FIT format. We soon found that the FIT-SDK was a bit of a bottleneck, so I ran some benchmarks and found some issues. I'll skip the details and just focus on the most serious (and most easily fixed) one.
The Java-SDK for FIT encoding does not buffer file writes. The relevant file is
FitSDKRelease_XX.YY.00/java/com/garmin/fit/FileEncoder.java
I first encountered it in version 20.67 and have confirmed that it remains in version 21.20. The result is
1. While writing messages in bulk, the Java-encoder is very slow.
2. If physical memory is an SD-card (as it is in some smartphones) the risk of memory corruption increases vastly compared to buffered writes.
Attached is an edited variant of the FileEncoder class that solves the problem (I had to zip it because otherwise the forum software blocked me). I just wrapped the FileOutputStream in a BufferedOutputStream and made sure to flush it before file size is written to the header and final CRC is computed. Four lines have been added and one line has been edited. They are marked with comments
// ADDED LINE
and
// EDITED LINE
respectively.
Below is the result of encoding benchmarks using the original FIT-SDK compared with the case when FileEncoder is buffered. For reference I have also included the performance of the C++ and C SDKs. Note that the C-SDK creates much larger files than the others since it normally writes all fields that a particular message can hold, not just the ones whose values have been set.
Encoding time (seconds)
#records | original-java | edited-java | SDK-cpp | SDK-c
1e2 | 0.5 | 0.6 | 0.16 | 0.03
1e3 | 1.1 | 0.8 | 0.11 | 0.03
1e4 | 6.4 | 0.9 | 0.80 | 0.06
1e5 | 57.6 | 3.4 | 6.83 | 0.45
1e6 | ---- | 28.6 | 65.60 | 4.82
1e7 | ---- | 268.3 | ---- | 110.18
Note the non-linear scaling of encoding time with number of records for the Java cases is most likely due to JVM optimizations kicking in.
The edited variant is roughly an order of magnitude faster than the original.
If there is interest, I can post full encoding and decoding benchmarks including source code, compilation instructions and runtimes on three different systems (2*Windows+1*Linux).
