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

[Yuriy B. <Yur...@tr...>]

Hi,

I'm having a performance problem with my application, which uses =
QuickFix 1.12.4. After profiling I discovered that FIX::message_order =
constructor and copy operator both are very slow due to excessive heap =
allocation.

FIX::message_order class has rather na=EFve implementation, which uses =
array of ints for reverse lookup of the field ranks. This array is =
created/copied each time the field is created/copied, which happens a =
lot during the message construction. The array size is typically few K =
each (max field number * sizeof(int)), so all these copies cost you =
dear.

It's easy to implement light-weight copying just by using shared pointer =
to that array. (In my implementation I use either vector<int> or =
hash_map<int,int>, which are chosen in run-time depending on the =
predicted size).
The copy constructor and assignment operator then only copy shared =
pointer, not the array.

To make construction light-weight is more tricky. Currently, =
FIX::message_order is created on the stack and passed to FIX::Group =
constructor, as defined in message header files (src/C++/FIX44/*.h).=20

Ideally, you'd need one instance of FIX::message_order class per field =
type. The simplest way to do it is to initialise each FIX::Group with =
static instances of FIX::message_order. But this would require making =
.cpp file per each message header file, and adding them to the =
project/makefile.

I can post solution for FIX::message_order here, but it is not clear how =
to solve the problem with cpp files. I played a bit with ruby code which =
generated CPP sources, but adding 159 cpp files to the project seems to =
be quite a big change.

Regards,

Yuriy Baranovskyy