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

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

Actually, the speed improvement for regular messages was more 
significant than I thought, so the performance has improved all around.

I tried reserving space on the m_data member, but this actually hurt 
performance a bit.  The idea is good, but I figured this technique 
might be more effective on larger strings.  So instead instead I tried 
reserving space in the calculateString call, and this made a huge 
difference.  I can now do a to string on the quote messages at a rate 
of 27,000+ per second (up from the previous 23,000+).  Right now I'm 
just making a simple assumption that each field will average about 20 
characters.  Maybe this can be made smarter, but I think this is a 
reasonable assumption for most messages.  I'm happy to err on the side 
of reserving too much.  Speed versus size is a good tradeoff here since 
messages tend to be temporary objects, and generally aren't kept around 
in large quantities.

I've checked these changes if anyone wants to take a look at what was 
done and maybe suggest some other ideas.

--oren

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...
>