Re: [Quickfix-developers] Details for Solaris / SunPRO 5.3 build

[Oren M. <or...@qu...>]

Yeah, I think there is quite a few things that can be done.  I modified 
the method declaration of calculate string from:

std::string calculateString()

to:

std::string& calculateString( std::string& )

This gave some interesting results.  For normal messages this gave a 
small to negligible performance improvement to the messages toString() 
implementation.  I rather expected this.  But, for messages with 
repeating groups (MassQuote messages with 10 groups), the performance 
of toString() improved something like 80-90%.  Previously the machine I 
was benchmarking was able to convert these messages to strings at a 
rate of about 12,000+ per second, after the change it was 22-23000+ per 
second.

It would be nice to see if we can focus on improving message 
construction for messages with repeating groups.  Although we can 
convert these to strings rather quickly, I was only able to construct 
1700 of these messages objects per second on the same hardware.  This 
is actually quite good considering the size of the messages, but I 
think more can be done.  One of the reasons repeating groups is slower 
is that they have the odd requirement of having the fields sorted in a 
specific order.  If we are talking to an engine that doesn't care about 
this (say, for instance, QuickFIX), it would be nice to construct the 
messages without the need for this overhead.

On Jul 13, 2004, at 4:01 PM, Caleb Epstein wrote:

> On Tue, 13 Jul 2004 13:54:50 -0500, Oren Miller 
> <or...@qu...> wrote:
>
>> I noticed you replaced some sprintf calls with ostringstreams.  We
>> actually used to do this, but performance testing revealed that the
>> sprintf calls were considerably faster.  I don't remember the exact
>> numbers, but I believe using the sprintf calls made message
>> construction something on the order of 10% faster.  That's pretty
>> significant.  Is there a particular reason you changed these?
>
>      On Linux I've definitely found this to be the case.  Using
> sprintf to do the formatting and just sending char*'s to the iostreams
> is considerably faster.  You can optimize even further by collecting
> the return value of sprintf and using ostream::write (const char*,
> streamsize) instead of ostream::operator<<, which will avoid at least
> a strlen call.  Taken together, I think these will give you a good
> deal more than a 10% performance improvement.
>
>      I think there is some additional optimization that could be done
> inside the QF Field class by reserving an appropriate amount of
> storage for m_data in the setString method before assigning to it.  We
> have found std::string::append to be a bottleneck when doing this sort
> of thing on Linux.  It would have to be a bit of a guesstimate though,
> since you don't know the number of digits in the ASCII representation
> of the tag.
>
> -- 
> Caleb Epstein
> cal...@gm...
>