[This message was posted by Rolf Andersson of Pantor Engineering <[email protected]> to the "FAST Protocol" discussion forum at http://fixprotocol.org/discuss/46. You can reply to it on-line at http://fixprotocol.org/discuss/read/06240ab5 - PLEASE DO NOT REPLY BY MAIL.]
> - What is the "exact" processing overhead of FAST field and transfer > encoding respectively? I may have been somewhat imprecise or implicit when posing the question above. There are several different questions embedded here: 1. What is the processing overhead of the field encoding? 2. What is the processing overhead of the transfer encoding? 3. How does the processing overhead vary depending on the input data? 4. How does the processing overhead of the transfer encoding vary depending on the processing overhead of the field encoding? A variation of q4 could be: How does the processing overhead of field encoding and transfer encoding respectively correlate for individual messages? I recall that during testing in June 2005, we found a few cancel messages in the ARCA test data set that ended up being encoded as a pmap only. Every field (incl the tid) was defaulted after field encoding. So, while field encoding took some resources comparing and making the decision to default code each field value, the transfer encoding ended up passing a one-byte pmap. Obviously, this only happened very rarely, I believe we found less than a handful in the 77-million or so real messages used for testing of the ARCA feed. /Rolf [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
