[This message was posted by Marc Battyani of HPC Platform <marc.batty...@hpcplatform.com> 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/c644c633 - PLEASE DO NOT REPLY BY MAIL.]
Hi Dale, This is a recurrent topic ;-) I posted about this earlier and I still think it should be a mandatory attribute in the templates. Proposal for a MaxLength string attribute: http://fixprotocol.org/discuss/read/702f62f0 maxLength attribute for strings and vectors: http://fixprotocol.org/discuss/read/e5c03358 Marc > Continuing my suggestions for improving FAST... > > Dynamic memory allocation can be a real performance killer. In C++ there > are a number of techniques that can be used to avoid dynamic memory > allocation or minimize its impact including keeping thread-specific > memory pools and caching objects for re-use rather than deleteing/newing > them, etc. > > The one technique I would like to use, however, eliminates dynamic > memory allocation altogether. That is preallocating space for the > largest possible message. I have been able to use this with data feeds > from particular sources to achieve some dramatic results. However, given > the current definition of FAST templates there is no way to achieve > these results in the general case, because there is no way to determine > what "the largest possible message" is. > > So my suggestion is add upper-bound information to field instructions > that produce variable sized objects. In particular, the sequence, > string, and byte vector instructions could have a bound="n" attribute > that would be a commitment by the data source/template author that field > being transmitted would never exceed 'n' elements. This information is > often available to the data source/encoder. Making it available in the > template would give the decoder the information it needs to avoid > dynamic allocation in the general case. > > Of course this would be an optional attribute with the default being > that the number of elements is unbounded (or at least indeterminate.) > > Dale > -- > Principal Software Engineer Object Computing, Inc (www.ociweb.com) Lead > Developer of the QuickFAST Open Source C++ implementation of the FAST > protocol. (www.quickfast.org) [You can unsubscribe from this discussion group by sending a message to mailto:unsubscribe+100932...@fixprotocol.org] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to fix-proto...@googlegroups.com. To unsubscribe from this group, send email to fix-protocol+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
