How fast is QuickFix ?

In my firm we are beginning a new OMS (Order Management System) project and there is a debate whether we use Quickfix or we go for a professional fix engine? Because there is a common doubt that QuickFix is not enough fast and obviously we will not get any technical support. I heard that in BOVESPA it has been used for a while. They are changing it with a paid one now. Well that is enough for me. If they use it I can use it.

Should I choose a professional one over QuickFix? Is it not good enough?

-

In order to answer your question (for you) you would need something to compare to. You would need numbers to know if it is slower/faster, how much, and if it will impact your system overall. Also knowing your performance goals could narrow down the options.

My advice is to take a look at your overall architecture of the sytem you have or intend to build. To just look at QuickFIX is rather meaningless without the whole chain involved in processing information and reacting to it. As an example, say QuickFIX is 100 times faster than some part (in the chain of processing) you have or build. Now, replacing QuickFIX with another part which is 100 times faster than QuickFIX would not change anything because you're still held back by the slowest point. And remember that network hops are usually very expensive compared to in-memory processing of data.

If you for some reason cannot compare different candidates against each other, why not start with e.g. QuickFIX, but make the system in such a way that it can be replaced with something faster later on.

Generally speaking, QuickFIX is not the fastest option, but the key point is that it might not have to be. If performance is very critical and one has resources, you usually end up buying something or building something yourself. Drawbacks here are having resources like time, money and skilled people.

To answer your question better one would need to know other aspects as well, like available resources (money, time, skill), overall system overview, performance expectations and other factors that limit decisions. E.g. if money is not a limiting factor, just find the fastest option and buy it.

-
+1. I like this answer! – olaker Mar 10 '11 at 13:12

Compared to commercial offerings, Quickfix isn't that bad - considering you can pay \$10000's for the very best ULL engines.

I have conducted side by side testing of Quickfix and Fix8 measuring encode/decode latency for NewOrderSingle(D) messages, see here.

-
 I noticed a typo in your tables. "Average µs/msg" should read "Average s/msg". – kristine Jan 29 at 10:41 Thanks for spotting that. – dakka Jan 29 at 11:58 You're welcome. Thank you very much for compiling those results. – kristine Jan 29 at 12:13

We use internally optimized version of Quickfix. It gives us ~30 microsecond latency. Commercial products, like Onix or RapidAdvantage FIX will give you twice less.

-
 ty for numbers! – Gracchus Jun 4 at 2:50

I work in a big hedge fund and our DMA is entirely based on quickfixj with hundreds of trades a day and thousands of fills.

Quickfixj sits at the end of the OMS connecting to various counterparties and is in use since 2009, I think. Number of orders vary, possibly 150-450 a day, obviously with a lot more fills coming back than that number. Latency from an order entering the OMS to the fix message being sent is perhaps 150ms -- we are not aiming to be low latency at all though.

Using quickfixj is absolutely pain free.

-
Welcome to quant.SE! Can you elaborate a bit on your usage of QuickFixJ? How many orders per day? Do you measure order to accept latency? Some informative stats about your usage would be very interesting. – Louis Marascio Sep 10 '11 at 12:19
Quickfixj sits at the end of the OMS connecting to various counterparties and is in use since 2009, I think. Number of orders vary, possibly 150-450 a day, obviously with a lot more fills coming back than that number. Latency from an order entering the OMS to the fix message being sent is perhaps 150ms -- we are not aiming to be low latency at all though. Using quickfixj is absolutely pain free. – jk3000 Sep 10 '11 at 15:58
Thanks for the additional data! Can you edit you answer and include it there? That way it won't be missed if folks aren't reading comments. I'm out of votes right now, but will up vote you in a few hours. – Louis Marascio Sep 10 '11 at 16:00
Number of orders vary, possibly 150-450 a day. To put things into perspective, a market maker may send 1500--4500 orders per second. – chrisaycock Sep 10 '11 at 22:53

Bovespa is starting to release the new trade platform; take a look for yourself.

The BM&FBOVESPA PUMA Trading System will incorporate all of the functionalities that currently exist in the BM&FBOVESPA trading systems. Its trading speed will be less than a millisecond. In addition, the new platform will allow trading on the following markets: equities in the cash market, futures, options on futures and on actuals, spot US dollar, federal government bonds, private fixed-income securities, and spot commodities.

IMHO, quickfix needs to be patched/improved in order to handle such latency. (:

-

there is also an alternative to use a professional FIX Engine (B2BITS FIX Antenna C++) that includes a QuickFIX interface adaptor now. You can develop your project in C++ using the QuickFIX interface and if you decide to go faster you can consider our engine with QF adaptor. And then the cost is substantially lower to the cost of developing it in house.

-Dmitri

-
 Is this an ad? ;) – murrekatt Mar 10 '11 at 13:29 is that something you might be interested in? youtube.com/watch?v=jBh0SpDoVZw – Gracchus Jun 4 at 2:50

Forget about BOVESPA nobody in Brazil is really doing anything that relies on speed and stability. I can say that from my personal experience. I would say that depending on your demands QuickFIX can be as good as FIX.

-

How fast do you need? Have you measured round-trip times from the exchange and determined that you need a better solution?

I wouldn't call QuickFix quick; it has a lot of unnecessary overhead (temporary objects, temporary strings, nested functions, etc). But I've used it in projects before without too much trouble.

It is definitely possible to make a much faster FIX engine from scratch. You can use inlined accessors, call writev() instead of concatenating strings, etc. Then there's the standard's requirements, like replaying old FIX messages or handling multiple values per one key. It's a ton of work to do something like that correctly, so you'll need to evaluate just how much pain you're willing to go through.

I haven't used any of the commercial off-the-self engines; hopefully someone else can chime-in with a specific recommendation there. Ideally the cost of that will be a fraction of doing it in-house.

-
 Care to elaborate on "But I've used it in projects before without too much trouble."? I'm also curious on what optimization level you had the compiler at whilst using QuickFix. – bruce.banner Feb 19 '11 at 13:53