Re: [Quickfix-developers] Performance issue: FIX::message_sorter

[Oren M. <or...@qu...>]

If you have a superior implementation please submit it so we can =20
verify and apply it.  The current implementation is not naive, it was =20=

specifically chosen for its superior performance characteristics for =20
most common scenarios.  This includes using std::collection classes =20
which provided a far far slower implementation for sorting fields =20
which is the predominant bottleneck in creating messages with =20
repeating groups.

--oren

On Jul 9, 2007, at 11:40 AM, Yuriy Baranovskyy wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi,
>
> I'm having a performance problem with my application, which uses =20
> QuickFix 1.12.4. After profiling I discovered that =20
> FIX::message_order constructor and copy operator both are very slow =20=

> due to excessive heap allocation.
>
> FIX::message_order class has rather na=EFve implementation, which =20
> uses array of ints for reverse lookup of the field ranks. This =20
> array is created/copied each time the field is created/copied, =20
> which happens a lot during the message construction. The array size =20=

> is typically few K each (max field number * sizeof(int)), so all =20
> these copies cost you dear.
>
> It's easy to implement light-weight copying just by using shared =20
> pointer to that array. (In my implementation I use either =20
> vector<int> or hash_map<int,int>, which are chosen in run-time =20
> depending on the predicted size).
> The copy constructor and assignment operator then only copy shared =20
> pointer, not the array.
>
> To make construction light-weight is more tricky. Currently, =20
> FIX::message_order is created on the stack and passed to FIX::Group =20=

> constructor, as defined in message header files (src/C++/FIX44/*.h).
>
> Ideally, you'd need one instance of FIX::message_order class per =20
> field type. The simplest way to do it is to initialise each =20
> FIX::Group with static instances of FIX::message_order. But this =20
> would require making .cpp file per each message header file, and =20
> adding them to the project/makefile.
>
> I can post solution for FIX::message_order here, but it is not =20
> clear how to solve the problem with cpp files. I played a bit with =20
> ruby code which generated CPP sources, but adding 159 cpp files to =20
> the project seems to be quite a big change.
>
> Regards,
>
> Yuriy Baranovskyy
>
> ----------------------------------------------------------------------=20=

> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>