[FAST-20] Reusable Message Object Pool Created: 30/Oct/08  Updated: 31/Oct/08

Status: Open
Project: OpenFAST
Component/s: Message Object Model
Affects Version/s: None
Fix Version/s: 1.2.0

Type: New Feature Priority: Major
Reporter: Jacob Northey Assignee: Jacob Northey
Resolution: Unresolved Votes: 1
Labels: None


 Description   

The reusable message object pool will be used by a decoder to reuse existing message objects instead of recreating messages.

ReusableMessageObjectPool messagePool = new ReusableMessageObjectPool();
FastDecoder decoder = new FastDecoder(context, in);
decoder.setMessageFactory(messageFactory);
Message message = decoder.readMessage();
process(message);
messagePool.reuse(message);

This should decrease Unnecessary Object Creation and dramatically increase decoder performance.

 Comments   
Comment by Jörg Thönnes [ 31/Oct/08 ]

Hi Jacob,

why do you think that implementing an own message pool would improve general performance?

As far as I know, the Java garbage collector is quited sophisticated now with the young and the
old generation. For Java 7, also object allocation on the stack avoiding any garbage collection is
planned. Just wondering whether you have any concrete evidence to implement these features.

Thanks, Jörg

Comment by Jacob Northey [ 31/Oct/08 ]

Hi Jorg,

I've received an open source license to the YourKit Java Profiler. In the upcoming 1.0.1 release I've managed to make a 15-20% decrease in decoding time (of CME data) by analyzing the decoder in the profiler. Right now the only thing that is taking time during decoding is object creation. Since each message requires an array allocation as well as at least one object for every field, reusing the message objects might improve performance.

The default implementation would be not to use the ReusableMessageObjectPool, but a basic MessageFactory with immutable field objects. Once this task is implemented, we will see if there are any performance improvements from this approach.

Regards,
Jake

Generated at Sat Nov 23 17:41:44 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.