[QFJ-736] performance improvement: Modify the code to use StringBuilder instead of StringBuffer in calculateString method of FieldMap Created: 18/Mar/13  Updated: 02/Apr/15  Resolved: 14/Mar/14

Status: Closed
Project: QuickFIX/J
Component/s: Engine
Affects Version/s: 1.5.2
Fix Version/s: 1.6.0

Type: Improvement Priority: Default
Reporter: Srinivas Kirti Teja Rao Assignee: Christoph John
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
is related to QFJ-740 Replace StringBuffer with StringBuilder Closed

 Description   

The calculate string method expects a StringBuffer and does all the concatenation on this object. This can be changed to StringBuilder to improve performance. All most of the applications want to log an incoming or outgoing messages and improvement in this calculate string can help them.

protected void calculateString(StringBuffer buffer, int[] preFields, int[] postFields)



 Comments   
Comment by Ryan Lea [ 21/Mar/13 ]

I actually think it might be even more performant to use cached CharBuffer's as they don't need resizing (once they're at their desired size) and can be easily reused.

Comment by Christoph John [ 21/Mar/13 ]

Speaking of cached objects, we also need to take the concurrent access to the FieldMap/Message classes into account. So we either need to make the using methods thread-safe or clearly document that they are not.

Comment by Peter Lawrey [ 25/Apr/13 ]

A pre-allocated StringBuilder doesn't need resizing any more than CharBuffer does, except it will resize if it needs to.

Instead of using StringBuffer or StringBuilder, I suggest using the interface Appendable. This supports either, or a wrapper for CharBuffer or ByteBuffer (Given most FIX messages are ISO-8859-1 compliant i.e. don't need char anyway)

I agree the documentation should state whether it is thread safe or not, but as suggested in QFJ-740 it is not thread safe now which might be confusing given it is using StringBuffer.

Comment by Jörg Thönnes [ 25/Apr/13 ]

Peter, as you write "most FIX messages are ISO-8859-1 compliant"...

There have been requests in the past to allow international characters, so we should not block this route.
But yes, at the bottom encoding level we talk about ISO-8859-1 encoded chars which are bitwise identical to the raw bytes the FIX checksum algorithm is working on.

Comment by Christoph John [ 03/May/13 ]

@Peter: nice article. http://java.dzone.com/articles/why-synchronized-stringbuffer

Comment by Christoph John [ 14/Mar/14 ]

http://sourceforge.net/p/quickfixj/code/1147/

Generated at Sat Nov 23 05:20:09 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.