[QFJ-127] quickfix performance Created: 24/Jan/07  Updated: 10/Feb/07  Resolved: 10/Feb/07

Status: Closed
Project: QuickFIX/J
Component/s: Engine
Affects Version/s: 1.0.4
Fix Version/s: None

Type: Other Priority: Default
Reporter: rohit Assignee: Steve Bate
Resolution: Fixed Votes: 0
Labels: None
Environment:

test


 Description   

Hi Steve,
We are trying to evaluate using QF engine using java api and found new issues. The message creation by just using the data dictionary that comes with FIX.4.2.xml is taking longer than just adding required fields. Our application is very powerful and don't want to add any extra latency. But, when I did some stats, I found QF message creation takes longer time (say for MktdataIncRefresh) if I use groups. I changed the Message.java where I can now do addfield as list and create the message witout using Groups. That's 3 times faster. I understand that the way the java code is written and really superb. But, it affected the performance in big time.

say if I want
1) add desired fields
2) add groups as a list

currently I can't do it with QF. I have to use setField and addgroup methods.

also I found another prb where the send and processmessage methods are synchronized. I guess this is done for sequence numbers. why do we want to lock the object by putting synchronized in the methods?

pls advise. I am anyway going to change as per my requirements.

Thanks for all the great help and support..

Cheers
Rohit

 Comments   
Comment by Steve Bate [ 24/Jan/07 ]

Hello Rohit,

Can you add an issue attachment with your modified version of the Message class and your timing tests for message creation? I'm not sure I understand what you mean by adding fields as a list and why that would be faster. Have you done any profiling to understand the reason for the performance differences?

I assume the processMessage method you are referencing is the one in SingleThreadedEventHandlingStrategy. It's not synchronized, so I'm guessing your concern is about the synchronized Session.next method. If so, you are correct that the synchronization is there to protect session state and ensure is visibility in mulththreaded, multiprocessor applications. What exactly is the problem? Are you having issues with processing high rates of simultaneously incoming and outgoing messages or something else?

Steve

Comment by rohit [ 31/Jan/07 ]

Hi Steve,
Thanks for the info. What I meant was, currently the Message construction (FieldMap) use TreeMap to build the fix message in a proper order(especially for grous). When I tested the message creation times with the default data dictionary, it's taking more time compared to linearly adding fields without worrying about the group order etc. In this case, the user is responsible to add the elements in proper order. The change I made is added "addField()" method which actually maintain an ArrayList and when toString() is called, it will just add in the order. I found the message creation times are 3 times faster than using setField methods. I am talking the times in micro seconds. But, our app creates 1000 of updates in a second. So, it did make a big difference to my app. I will attach the code tomorrow when I am in office.

Thanks as always for the great support. Cheers.

Comment by Sankalp Nayak [ 02/Feb/07 ]

Hi Rohit

Did you also tested the performance while retreiving the different tag-value pairs, ie the "fromString()" method . I guess moving from TreeMap to List may improve the creation performance but may significantly affect the retrieval performance esp if the groups are large in size . It would be interesting to profile that also .

thanks
Sankalp

Comment by Steve Bate [ 10/Feb/07 ]

There have been some performance-related QFJ discussions on the QuickFIX (not QFJ) list.

Generated at Sat Nov 23 10:52:04 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.