[Quickfix-developers] Performance issue: FIX::message_sorter
Brought to you by:
orenmnero
|
From: Yuriy B. <Yur...@tr...> - 2007-07-09 16:40:30
|
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 |