[This message was posted by Brandon Yuille of BWY Systems <[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/4578f8c9 - PLEASE DO NOT REPLY BY MAIL.]
Thanks for the response David, To clarify, yes it's not finding the length of the PMAP that bothers me. My implementation does not access outside memory for storage so I must loop through the PMAP bits twice. So lets look at the type of implementation you mentioned, they scan the bits first and store them in some way (ie copy them to another memory location), but because they don't know what the template id this will require them to access that storage memory again to update the template fields once the template id is found (probably resulting in a second memory copy). So even in the scenario you mention, the decoder must reread the bits again from the storage memory (which is equal to looping twice) to update the individual template fields with their PMAP bits. I hope that make sense. Really though, it's not a big deal, the processing time is very minimal. I was just curious why the template id is stored where it is, as it is clear the template id must be known to do anything with the PMAP at all. That's why I was suggesting that if there is to be another FAST version, it might be a good update to move the template id to the beginning of the message and you can even set it to NULL if it is to be copied from a previous message. Brandon > The tid appears after the pmap so it can be optimized away most of the > time using the implicit copy operator. It not only saves you bytes on > the wire, it also allows you to save table lookups and similar > operations depending on your implementation. > > Not sure what you mean by reading the pmap twice though. Every > implementation I've seen so far do the stop bit scanning once, store the > bits in some way or other, then access the stored bits in order. So if > you mean memory/register accesses I'd say there is at least one for > every bit in the pmap. Even if you don't use intermediary storage for > the decoded pmap, you should get away with finding its length once. And > I don't see how the placement of the tid would change that. > > /David > > > After seeing a lot of complaints about FAST on this forum, I'd first > > like to say to the creators that I personally like FAST encoding. At > > first I was taken aback by the complexity, which I think is the source > > of most complaints. However once I had a full understanding of the > > specification, I realized the beauty of FAST and without it's > > complexity it would never be able to accomplish what it does. > > > > I do have one comment or question though... Why does the template id > > field come after the PMAP? Is there an implementation of FAST which > > does not use templates? > > > > The reason I ask is because in my FAST decoder there is no way I can > > figure to decode without first looping through the PMAP to see if the > > template id is present, looking for the stop bit, extracting the > > template id, then starting all over (now that I know the template id) > > and reparsing the PMAP along with skipping over the template id. > > > > To me this seems inefficient to loop through the same bytes twice. > > Everywhere else my decoder never touches the same bytes twice. I > > really can't figure there is a solution to this, but maybe I'm wrong? > > Anyway, if there was one change I could make, that would be to have > > the template id be a mandatory field which precedes the PMAP and also > > remove the template id bit from the PMAP. [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.
