Re: [Quickfix-developers] 4.2 MessageCracker/MessageFactory efficiency

[Rick L. <ric...@gm...>]

the point is probably moot -- it seems that Session.sendToTarget() is really
the bottleneck.  We're seeing roughly 250-300 microseconds (or 80% of our
entire internal latency) for this call alone.  I wonder if anyone has had
any success in speeding this up?  is it simply the socket API that is this
slow?

On Wed, Nov 18, 2009 at 4:04 PM, Rick Lane <ric...@gm...> wrote:

> Greetings,
>
> We were recently taking a look through the FIX42_MessageCracker and
> MessageFactory code (we're using the .NET wrapper for Quickfix)  to see if
> we could make some improvements in our order routing internal latency.  We
> noticed that in both crack() and create()
>
> 1) it was doing string comparisons for the message type (when for FIX 4.2
> all message types are a single character)
> 2) it was doing if-statements rather than a switch statement
> 3) the if-statement for ExecutionReport (which is the most frequent type of
> message) was 30th in this list!
>
> So we figured we could speed this up substantially by:
>
> 1) creating a switch() statement (that is constant time) instead of 60 or
> so if-statements and
> 2) simply switch on the int value of the character (since we know it's only
> 1 character)
>
> However, in practice, we haven't noticed any speed gains and we almost seem
> to think we're seeing *slower *performance (this is tough to measure
> because we have to measure in conjunction with WireShark to see how long the
> message was outside our server (transit latency) and subtract that from the
> measured time in code).
>
> We're wondering if perhaps we aren't doing something correctly at compile
> time, if anyone has seen these if-statements and thought the same thing we
> thought, and if anyone has any input in general here.
>
> Any help is greatly appreciated.
>
> Rick
>
> P.S.  I'm not sure what the process is (it's been so long now) but if you
> could add dan...@ti... to the mailing list so it will accept
> emails from him.  Thanks again.
>