@nbdnnm I didn't fully grok your original question when I replied. I now get that you are talking about a custom CAN bus source device you are building. hence your question.
Regarding conversion - I stand by my original answer that RC conversions are pretty comprehensive and quick CPU wise. If this is a product you're planning on marketing / distributing globally then I suggest that where applicable you denominate your published CAN channels in metric / SI units and then let RC or whatever lap timer app take it from there. this will be consistent with automotive ECU behavior.
Regarding the new question on "compressing" or "packing". I have just in the last couple of days validated the RC does properly reassemble multi-frame ISO-TP messages before applying formatting. This is a really big deal, as there are numerous types of queryable ECU blobs that don't fit in an 8 byte CAN message. For example I just published brake pressure actual via x22 40 10 UDS DID query on Cayman Continental ECU. The reply is a 26 byte payload, which requires 4 sequential CAN frames to send. Given reassembly is almost certainly happening at a driver or other low level I doubt you would pay a serious CPU penalty if you truly have a lot to send.
If some of your data is "fast" and less voluminous, and other data is "slow" refresh and more voluminous, this might suggest a strategy of pack as much of the fast stuff as you can in an 8 byte CAN frame just to avoid the layer 2 reassembly overhead, and then use the multi-frame for larger (>8 byte) payloads.
To give you some idea of CAN speed, as noted elsewhere here and on 718 Forum I am capturing 1ms level variances with standard 8 byte CAN from ultra high-speed ECU channels (e.g. brake pressure updating fast enough to see ABS activity in the trace into high speed braking corners).
