Performance latency improvement when sending messages

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Performance latency improvement when sending messages

Charles Briquel
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

At our work we are sending lot of market datas and I noticed that quickfixj consume a lot of memory for this task, with lead to many minor GC collections, introducing many pauses.

I previously saw on this mailing list that someone contributed on the decoding message allocations, I can contribute for the encoding message part.
By reading the code I saw some inelegant things, may be due to the fact that different programmers have contributed to this api and may have broke some initial optimizations (I think to the fact that Field encoding seems to be initially cached, but cached String value is not reused).

Anyway, I managed to reduce the memory allocation by about 90% in our environment, by making little optimizations.

Would you be interested by them ?
I can give you details about each one and try to validate them over your unit tests if you help me for this task. I validated them by running our code in prod' environment and checking there is no regression for us.

Regards,

Charles Briquel


------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: Performance latency improvement when sending messages

Ishmael Rufus
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Is this specific to the latest version or have you seen this with other versions of QuickFIXJ?

On Thu, Jul 23, 2015 at 9:03 AM, Charles Briquel <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

At our work we are sending lot of market datas and I noticed that quickfixj consume a lot of memory for this task, with lead to many minor GC collections, introducing many pauses.

I previously saw on this mailing list that someone contributed on the decoding message allocations, I can contribute for the encoding message part.
By reading the code I saw some inelegant things, may be due to the fact that different programmers have contributed to this api and may have broke some initial optimizations (I think to the fact that Field encoding seems to be initially cached, but cached String value is not reused).

Anyway, I managed to reduce the memory allocation by about 90% in our environment, by making little optimizations.

Would you be interested by them ?
I can give you details about each one and try to validate them over your unit tests if you help me for this task. I validated them by running our code in prod' environment and checking there is no regression for us.

Regards,

Charles Briquel


------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



--
Ishmael Rufus - Programmer 
Ditto Holdings, Inc. 
200 W. Monroe St. 
Suite 1430
Chicago, IL 60606
(312)263-5400

------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: Performance latency improvement when sending messages

Charles Briquel
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



We were using version 1.5.3, but I made my changes over the 1.6.0 version, as it was quite the same code.
There is no regression about memory consumption from 1.5.3 to 1.6.0 as far as I've seen.
I used JMC to tracks them, or simply read the code.

The class I patched are the following :

mina/message/FIXMessageEncoder
BooleanField
DataDictionary
DateField
DoubleField
Field
FieldMap
Message
Session
SLF4JLog
UtcDateOnlyField
UtcTimeOnlyField
UtcTimeStampField

field/converter/AbstractDateTimeConverter
field/converter/CharConverter
field/converter/DoubleConverter
field/converter/IntConverter
field/converter/UtcDateOnlyConverter
field/converter/UtcTimeOnlyConverter
field/converter/UtcTimeStampConverter

And I added two classes :

CharSequenceReader -> it's the code from the official jdk7 to parse a CharSequence to get a double (from the jdk7, Double::parseDouble(String s) need a String, which lead to an allocation) :    public static double valueOf(CharSequence in) throws NumberFormatException

NumbersCache -> some hardcoded String values for simple number, to avoid many allocations for numbers (when doing String::valueOf(..) ) :
public static String get(long i)
public static String get(double d)






Le 23 juil. 2015 à 10:06, Ishmael Rufus a écrit :

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Is this specific to the latest version or have you seen this with other versions of QuickFIXJ?

On Thu, Jul 23, 2015 at 9:03 AM, Charles Briquel <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J
Support: http://www.quickfixj.org/support/


Hi,

At our work we are sending lot of market datas and I noticed that quickfixj consume a lot of memory for this task, with lead to many minor GC collections, introducing many pauses.

I previously saw on this mailing list that someone contributed on the decoding message allocations, I can contribute for the encoding message part.
By reading the code I saw some inelegant things, may be due to the fact that different programmers have contributed to this api and may have broke some initial optimizations (I think to the fact that Field encoding seems to be initially cached, but cached String value is not reused).

Anyway, I managed to reduce the memory allocation by about 90% in our environment, by making little optimizations.

Would you be interested by them ?
I can give you details about each one and try to validate them over your unit tests if you help me for this task. I validated them by running our code in prod' environment and checking there is no regression for us.

Regards,

Charles Briquel


------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



--
Ishmael Rufus - Programmer 
Ditto Holdings, Inc. 
200 W. Monroe St. 
Suite 1430
Chicago, IL 60606
(312)263-5400
------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: Performance latency improvement when sending messages

Charles Briquel
In reply to this post by Ishmael Rufus
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



We were using version 1.5.3, but I made my changes over the 1.6.0 version, as it was quite the same code.
There is no regression about memory consumption from 1.5.3 to 1.6.0 as far as I've seen.
I used JMC to tracks them, or simply read the code.

The class I patched are the following :

mina/message/FIXMessageEncoder
BooleanField
DataDictionary
DateField
DoubleField
Field
FieldMap
Message
Session
SLF4JLog
UtcDateOnlyField
UtcTimeOnlyField
UtcTimeStampField

field/converter/AbstractDateTimeConverter
field/converter/CharConverter
field/converter/DoubleConverter
field/converter/IntConverter
field/converter/UtcDateOnlyConverter
field/converter/UtcTimeOnlyConverter
field/converter/UtcTimeStampConverter

And I added two classes :

CharSequenceReader -> it's the code from the official jdk7 to parse a CharSequence to get a double (from the jdk7, Double::parseDouble(String s) need a String, which lead to an allocation) :    public static double valueOf(CharSequence in) throws NumberFormatException

NumbersCache -> some hardcoded String values for simple number, to avoid many allocations for numbers (when doing String::valueOf(..) ) :
public static String get(long i)
public static String get(double d)



On Thu, Jul 23, 2015 at 10:06 AM, Ishmael Rufus wrote :

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Is this specific to the latest version or have you seen this with other versions of QuickFIXJ?

On Thu, Jul 23, 2015 at 9:03 AM, Charles Briquel <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J
Support: http://www.quickfixj.org/support/


Hi,

At our work we are sending lot of market datas and I noticed that quickfixj consume a lot of memory for this task, with lead to many minor GC collections, introducing many pauses.

I previously saw on this mailing list that someone contributed on the decoding message allocations, I can contribute for the encoding message part.
By reading the code I saw some inelegant things, may be due to the fact that different programmers have contributed to this api and may have broke some initial optimizations (I think to the fact that Field encoding seems to be initially cached, but cached String value is not reused).

Anyway, I managed to reduce the memory allocation by about 90% in our environment, by making little optimizations.

Would you be interested by them ?
I can give you details about each one and try to validate them over your unit tests if you help me for this task. I validated them by running our code in prod' environment and checking there is no regression for us.

Regards,

Charles Briquel


------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



--
Ishmael Rufus - Programmer 
Ditto Holdings, Inc. 
200 W. Monroe St. 
Suite 1430
Chicago, IL 60606
(312)263-5400
------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: Performance latency improvement when sending messages

Christoph John
In reply to this post by Charles Briquel
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi Charles,

thanks for your offer. We would be very interested in your contributions. :)

The easiest way would be if you had a github account and could create a pull request. The github
repo is at https://github.com/quickfix-j/quickfixj
Alternatively you could create a JIRA issue and attach your patches there:
http://www.quickfixj.org/jira/browse/QFJ

Cheers,
Chris.





On 23/07/15 16:03, Charles Briquel wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> At our work we are sending lot of market datas and I noticed that quickfixj consume a lot of memory for this task, with lead to many minor GC collections, introducing many pauses.
>
> I previously saw on this mailing list that someone contributed on the decoding message allocations, I can contribute for the encoding message part.
> By reading the code I saw some inelegant things, may be due to the fact that different programmers have contributed to this api and may have broke some initial optimizations (I think to the fact that Field encoding seems to be initially cached, but cached String value is not reused).
>
> Anyway, I managed to reduce the memory allocation by about 90% in our environment, by making little optimizations.
>
> Would you be interested by them ?
> I can give you details about each one and try to validate them over your unit tests if you help me for this task. I validated them by running our code in prod' environment and checking there is no regression for us.
>
> Regards,
>
> Charles Briquel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

--
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:[hidden email]
       


http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
         Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: Performance latency improvement when sending messages

Charles Briquel
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Okay,

Thanks for the explanations.
I'll do it as soon as I've got enough time, as I'm on vacations…
There is one point I wanted to ask, because I think it was already subject to polemic :
I dropped the TreeMap structures used to store fields and groups, by simple lists.
Because we do not have so many fields in our message, it's not less efficient for us.
I suppose you won't want this kind of change ?

Regards,



Le 24 juil. 2015 à 03:58, Christoph John a écrit :

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi Charles,
>
> thanks for your offer. We would be very interested in your contributions. :)
>
> The easiest way would be if you had a github account and could create a pull request. The github
> repo is at https://github.com/quickfix-j/quickfixj
> Alternatively you could create a JIRA issue and attach your patches there:
> http://www.quickfixj.org/jira/browse/QFJ
>
> Cheers,
> Chris.
>
>
>
>
>
> On 23/07/15 16:03, Charles Briquel wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Hi,
>>
>> At our work we are sending lot of market datas and I noticed that quickfixj consume a lot of memory for this task, with lead to many minor GC collections, introducing many pauses.
>>
>> I previously saw on this mailing list that someone contributed on the decoding message allocations, I can contribute for the encoding message part.
>> By reading the code I saw some inelegant things, may be due to the fact that different programmers have contributed to this api and may have broke some initial optimizations (I think to the fact that Field encoding seems to be initially cached, but cached String value is not reused).
>>
>> Anyway, I managed to reduce the memory allocation by about 90% in our environment, by making little optimizations.
>>
>> Would you be interested by them ?
>> I can give you details about each one and try to validate them over your unit tests if you help me for this task. I validated them by running our code in prod' environment and checking there is no regression for us.
>>
>> Regards,
>>
>> Charles Briquel
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
> --
> Christoph John
> Development & Support
> Direct: +49 241 557080-28
> Mailto:[hidden email]
>
>
>
> http://www.macd.com <http://www.macd.com/>
> ----------------------------------------------------------------------------------------------------
>
> ----------------------------------------------------------------------------------------------------
> MACD GmbH
> Oppenhoffallee 103
> D-52066 Aachen
> Tel: +49 241 557080-0 | Fax: +49 241 557080-10
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
>
> Geschäftsführer: George Macdonald
> ----------------------------------------------------------------------------------------------------
>
> ----------------------------------------------------------------------------------------------------
>
> take care of the environment - print only if necessary
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: Performance latency improvement when sending messages

Charles Briquel
In reply to this post by Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

I just made a first pull request.
It relates only to the FixMessageEncoder class, improving a little bit the allocations on this part.
It's not a silver bullet change, but eventually each one count and it's the most technical as it relate to mina layer and makes use of pool buffers.
What I can do is to commit some changes separately, it will be easier to select.
Regards,



Le 24 juil. 2015 à 03:58, Christoph John a écrit :

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi Charles,
>
> thanks for your offer. We would be very interested in your contributions. :)
>
> The easiest way would be if you had a github account and could create a pull request. The github
> repo is at https://github.com/quickfix-j/quickfixj
> Alternatively you could create a JIRA issue and attach your patches there:
> http://www.quickfixj.org/jira/browse/QFJ
>
> Cheers,
> Chris.
>
>
>
>
>
> On 23/07/15 16:03, Charles Briquel wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Hi,
>>
>> At our work we are sending lot of market datas and I noticed that quickfixj consume a lot of memory for this task, with lead to many minor GC collections, introducing many pauses.
>>
>> I previously saw on this mailing list that someone contributed on the decoding message allocations, I can contribute for the encoding message part.
>> By reading the code I saw some inelegant things, may be due to the fact that different programmers have contributed to this api and may have broke some initial optimizations (I think to the fact that Field encoding seems to be initially cached, but cached String value is not reused).
>>
>> Anyway, I managed to reduce the memory allocation by about 90% in our environment, by making little optimizations.
>>
>> Would you be interested by them ?
>> I can give you details about each one and try to validate them over your unit tests if you help me for this task. I validated them by running our code in prod' environment and checking there is no regression for us.
>>
>> Regards,
>>
>> Charles Briquel
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
> --
> Christoph John
> Development & Support
> Direct: +49 241 557080-28
> Mailto:[hidden email]
>
>
>
> http://www.macd.com <http://www.macd.com/>
> ----------------------------------------------------------------------------------------------------
>
> ----------------------------------------------------------------------------------------------------
> MACD GmbH
> Oppenhoffallee 103
> D-52066 Aachen
> Tel: +49 241 557080-0 | Fax: +49 241 557080-10
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
>
> Geschäftsführer: George Macdonald
> ----------------------------------------------------------------------------------------------------
>
> ----------------------------------------------------------------------------------------------------
>
> take care of the environment - print only if necessary
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: Performance latency improvement when sending messages

Charles Briquel
In reply to this post by Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

I finished to pull request everything, I hope quick fix is quicker now ; )

I did not pull treeMap replacement by lists, may be one day, as an optional behavior that we can set in the settings, if you like the rest.
I hope it is clean enough for you, I suppose we have to put a buffer size in settings if you take the FIXMessageEncoder change.

In our fx environnement, we dropped from gigabytes of allocated data in few minutes to one hundred of megabytes, we are brokers. This is not perfect but still 10 times better. It means 10 times less minor GC if quick fix is the only memory consumer…

Regards,

Charles


Le 24 juil. 2015 à 03:58, Christoph John a écrit :

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi Charles,
>
> thanks for your offer. We would be very interested in your contributions. :)
>
> The easiest way would be if you had a github account and could create a pull request. The github
> repo is at https://github.com/quickfix-j/quickfixj
> Alternatively you could create a JIRA issue and attach your patches there:
> http://www.quickfixj.org/jira/browse/QFJ
>
> Cheers,
> Chris.
>
>
>
>
>
> On 23/07/15 16:03, Charles Briquel wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Hi,
>>
>> At our work we are sending lot of market datas and I noticed that quickfixj consume a lot of memory for this task, with lead to many minor GC collections, introducing many pauses.
>>
>> I previously saw on this mailing list that someone contributed on the decoding message allocations, I can contribute for the encoding message part.
>> By reading the code I saw some inelegant things, may be due to the fact that different programmers have contributed to this api and may have broke some initial optimizations (I think to the fact that Field encoding seems to be initially cached, but cached String value is not reused).
>>
>> Anyway, I managed to reduce the memory allocation by about 90% in our environment, by making little optimizations.
>>
>> Would you be interested by them ?
>> I can give you details about each one and try to validate them over your unit tests if you help me for this task. I validated them by running our code in prod' environment and checking there is no regression for us.
>>
>> Regards,
>>
>> Charles Briquel
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
> --
> Christoph John
> Development & Support
> Direct: +49 241 557080-28
> Mailto:[hidden email]
>
>
>
> http://www.macd.com <http://www.macd.com/>
> ----------------------------------------------------------------------------------------------------
>
> ----------------------------------------------------------------------------------------------------
> MACD GmbH
> Oppenhoffallee 103
> D-52066 Aachen
> Tel: +49 241 557080-0 | Fax: +49 241 557080-10
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
>
> Geschäftsführer: George Macdonald
> ----------------------------------------------------------------------------------------------------
>
> ----------------------------------------------------------------------------------------------------
>
> take care of the environment - print only if necessary
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: Performance latency improvement when sending messages

Paul McCabe
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Hi Charles,

Many thanks for sharing your enhancements with the community, I'll take a look through them next week.

As for replacing the treemap in the FieldMap / Message related classes, I am of the opinion that Message should be an interface, so we can support multiple implementations* (I have experimented with similar modifications in the past). But I worry about compatibility - it could break a lot of people's code, and make an upgrade painful, so we would have to look at a 2.X.X release if such a change were to be introduced.

Paul.

* I have a situation where it would be really useful to handle repeating groups without a data dictionary, and without losing tags, for just forwarding on to another session, for example.

On 1 Aug 2015 09:01, "Charles Briquel" <[hidden email]> wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> I finished to pull request everything, I hope quick fix is quicker now ; )
>
> I did not pull treeMap replacement by lists, may be one day, as an optional behavior that we can set in the settings, if you like the rest.
> I hope it is clean enough for you, I suppose we have to put a buffer size in settings if you take the FIXMessageEncoder change.
>
> In our fx environnement, we dropped from gigabytes of allocated data in few minutes to one hundred of megabytes, we are brokers. This is not perfect but still 10 times better. It means 10 times less minor GC if quick fix is the only memory consumer…
>
> Regards,
>
> Charles
>
>
> Le 24 juil. 2015 à 03:58, Christoph John a écrit :
>
> > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> > QuickFIX/J Support: http://www.quickfixj.org/support/
> >
> >
> > Hi Charles,
> >
> > thanks for your offer. We would be very interested in your contributions. :)
> >
> > The easiest way would be if you had a github account and could create a pull request. The github
> > repo is at https://github.com/quickfix-j/quickfixj
> > Alternatively you could create a JIRA issue and attach your patches there:
> > http://www.quickfixj.org/jira/browse/QFJ
> >
> > Cheers,
> > Chris.
> >
> >
> >
> >
> >
> > On 23/07/15 16:03, Charles Briquel wrote:
> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> >> QuickFIX/J Support: http://www.quickfixj.org/support/
> >>
> >>
> >> Hi,
> >>
> >> At our work we are sending lot of market datas and I noticed that quickfixj consume a lot of memory for this task, with lead to many minor GC collections, introducing many pauses.
> >>
> >> I previously saw on this mailing list that someone contributed on the decoding message allocations, I can contribute for the encoding message part.
> >> By reading the code I saw some inelegant things, may be due to the fact that different programmers have contributed to this api and may have broke some initial optimizations (I think to the fact that Field encoding seems to be initially cached, but cached String value is not reused).
> >>
> >> Anyway, I managed to reduce the memory allocation by about 90% in our environment, by making little optimizations.
> >>
> >> Would you be interested by them ?
> >> I can give you details about each one and try to validate them over your unit tests if you help me for this task. I validated them by running our code in prod' environment and checking there is no regression for us.
> >>
> >> Regards,
> >>
> >> Charles Briquel
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> Quickfixj-users mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> >
> > --
> > Christoph John
> > Development & Support
> > Direct: +49 241 557080-28
> > Mailto:[hidden email]
> >
> >
> >
> > http://www.macd.com <http://www.macd.com/>
> > ----------------------------------------------------------------------------------------------------
> >
> > ----------------------------------------------------------------------------------------------------
> > MACD GmbH
> > Oppenhoffallee 103
> > D-52066 Aachen
> > Tel: +49 241 557080-0 | Fax: +49 241 557080-10
> >        Amtsgericht Aachen: HRB 8151
> > Ust.-Id: DE 813021663
> >
> > Geschäftsführer: George Macdonald
> > ----------------------------------------------------------------------------------------------------
> >
> > ----------------------------------------------------------------------------------------------------
> >
> > take care of the environment - print only if necessary
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Quickfixj-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: Performance latency improvement when sending messages

Charles Briquel
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Thanks for your return,

There is two points to note :

- The change for avoiding allocation of Double in DoubleField looks a little bit hacky, because it was not originally designed to handle scalars.

- I removed the check of input string in DoubleConverter, because it use regexp and it's not very efficient. I'll can write another one in a way similar to what is done in IntConverter if you want. It would be faster than regexp too.


And for the TreeMap, the only external impact that I found and would break something is the method 
Map<Integer, List<Group>> getGroups() from FieldMap.
I replaced it by : List<GroupList> getGroups()   (GroupList is an inherited ArrayList with an attribute added, the group tag)

May be we can just build a Map<Integer, List<Group>> when requesting this method an being in ArrayList mode, and add a 'getGroupLists()' method, this way it won't beak compatibility and programmers that would setup List for fields and groups for performance should know what they do…

Regards,


Le 1 août 2015 à 03:44, Paul McCabe a écrit :

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi Charles,

Many thanks for sharing your enhancements with the community, I'll take a look through them next week.

As for replacing the treemap in the FieldMap / Message related classes, I am of the opinion that Message should be an interface, so we can support multiple implementations* (I have experimented with similar modifications in the past). But I worry about compatibility - it could break a lot of people's code, and make an upgrade painful, so we would have to look at a 2.X.X release if such a change were to be introduced.

Paul.

* I have a situation where it would be really useful to handle repeating groups without a data dictionary, and without losing tags, for just forwarding on to another session, for example.

On 1 Aug 2015 09:01, "Charles Briquel" <[hidden email]> wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> I finished to pull request everything, I hope quick fix is quicker now ; )
>
> I did not pull treeMap replacement by lists, may be one day, as an optional behavior that we can set in the settings, if you like the rest.
> I hope it is clean enough for you, I suppose we have to put a buffer size in settings if you take the FIXMessageEncoder change.
>
> In our fx environnement, we dropped from gigabytes of allocated data in few minutes to one hundred of megabytes, we are brokers. This is not perfect but still 10 times better. It means 10 times less minor GC if quick fix is the only memory consumer…
>
> Regards,
>
> Charles
>
>
> Le 24 juil. 2015 à 03:58, Christoph John a écrit :
>
> > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> > QuickFIX/J Support: http://www.quickfixj.org/support/
> >
> >
> > Hi Charles,
> >
> > thanks for your offer. We would be very interested in your contributions. :)
> >
> > The easiest way would be if you had a github account and could create a pull request. The github
> > repo is at https://github.com/quickfix-j/quickfixj
> > Alternatively you could create a JIRA issue and attach your patches there:
> > http://www.quickfixj.org/jira/browse/QFJ
> >
> > Cheers,
> > Chris.
> >
> >
> >
> >
> >
> > On 23/07/15 16:03, Charles Briquel wrote:
> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> >> QuickFIX/J Support: http://www.quickfixj.org/support/
> >>
> >>
> >> Hi,
> >>
> >> At our work we are sending lot of market datas and I noticed that quickfixj consume a lot of memory for this task, with lead to many minor GC collections, introducing many pauses.
> >>
> >> I previously saw on this mailing list that someone contributed on the decoding message allocations, I can contribute for the encoding message part.
> >> By reading the code I saw some inelegant things, may be due to the fact that different programmers have contributed to this api and may have broke some initial optimizations (I think to the fact that Field encoding seems to be initially cached, but cached String value is not reused).
> >>
> >> Anyway, I managed to reduce the memory allocation by about 90% in our environment, by making little optimizations.
> >>
> >> Would you be interested by them ?
> >> I can give you details about each one and try to validate them over your unit tests if you help me for this task. I validated them by running our code in prod' environment and checking there is no regression for us.
> >>
> >> Regards,
> >>
> >> Charles Briquel
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> Quickfixj-users mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> >
> > --
> > Christoph John
> > Development & Support
> > Direct: +49 241 557080-28
> > Mailto:[hidden email]
> >
> >
> >
> > http://www.macd.com <http://www.macd.com/>
> > ----------------------------------------------------------------------------------------------------
> >
> > ----------------------------------------------------------------------------------------------------
> > MACD GmbH
> > Oppenhoffallee 103
> > D-52066 Aachen
> > Tel: +49 241 557080-0 | Fax: +49 241 557080-10
> >        Amtsgericht Aachen: HRB 8151
> > Ust.-Id: DE 813021663
> >
> > Geschäftsführer: George Macdonald
> > ----------------------------------------------------------------------------------------------------
> >
> > ----------------------------------------------------------------------------------------------------
> >
> > take care of the environment - print only if necessary
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Quickfixj-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: Performance latency improvement when sending messages

Christoph John
In reply to this post by Charles Briquel
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Hi Charles,
thanks for this. Much appreciated. I will have a closer look after my vacation.
Cheers,
Chris.

Am 1. August 2015 09:59:50 MESZ, schrieb Charles Briquel <[hidden email]>:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

I finished to pull request everything, I hope quick fix is quicker now ; )

I did not pull treeMap replacement by lists, may be one day, as an optional behavior that we can set in the settings, if you like the rest.
I hope it is clean enough for you, I suppose we have to put a buffer size in settings if you take the FIXMessageEncoder change.

In our fx environnement, we dropped from gigabytes of allocated data in few minutes to one hundred of megabytes, we are brokers. This is not perfect but still 10 times better. It means 10 times less minor GC if quick fix is the only memory consumer…

Regards,

Charles


Le 24 juil. 2015 à 03:58, Christoph John a écrit :

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi Charles,

thanks for your offer. W

------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: Performance latency improvement when sending messages

ChristopherH
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Hi,

  Is Charles's work easily accessible for anywhere (I was just interested as I do similar work on other engines) ?   I wanted a look and I'm not that up on my GIT, though migrating soon.

Chris



From: [hidden email]
Date: Sun, 2 Aug 2015 15:53:12 +0200
To: [hidden email]; [hidden email]
Subject: Re: [Quickfixj-users] Performance latency improvement when sending messages

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Hi Charles, thanks for this. Much appreciated. I will have a closer look after my vacation. Cheers, Chris. Am 1. August 2015 09:59:50 MESZ, schrieb Charles Briquel : >QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >QuickFIX/J Support: http://www.quickfixj.org/support/ > > >Hi, > >I finished to pull request everything, I hope quick fix is quicker now >; ) > >I did not pull treeMap replacement by lists, may be one day, as an >optional behavior that we can set in the settings, if you like the >rest. >I hope it is clean enough for you, I suppose we have to put a buffer >size in settings if you take the FIXMessageEncoder change. > >In our fx environnement, we dropped from gigabytes of allocated data in >few minutes to one hundred of megabytes, we are brokers. This is not >perfect but still 10 times better. It means 10 times less minor GC if >quick fix is the only memory consumer… > >Regards, > >Charles > > >Le 24 juil. 2015 à 03:58, Christoph John a écrit : > >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support: http://www.quickfixj.org/support/ >> >> >> Hi Charles, >> >> thanks for your offer. W
Hi Charles,
thanks for this. Much appreciated. I will have a closer look after my vacation.
Cheers,
Chris.

Am 1. August 2015 09:59:50 MESZ, schrieb Charles Briquel <[hidden email]>:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

I finished to pull request everything, I hope quick fix is quicker now ; )

I did not pull treeMap replacement by lists, may be one day, as an optional behavior that we can set in the settings, if you like the rest.
I hope it is clean enough for you, I suppose we have to put a buffer size in settings if you take the FIXMessageEncoder change.

In our fx environnement, we dropped from gigabytes of allocated data in few minutes to one hundred of megabytes, we are brokers. This is not perfect but still 10 times better. It means 10 times less minor GC if quick fix is the only memory consumer…

Regards,

Charles


Le 24 juil. 2015 à 03:58, Christoph John a écrit :

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi Charles,

thanks for your offer. W

------------------------------------------------------------------------------
_______________________________________________ Quickfixj-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: Performance latency improvement when sending messages

Charles Briquel
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Hi,

It should be accessible on git hub online, in the pull request section.
Bit I don't think it's transposable to other projects, except for the CharSequenceReader class which is code from ths jdk to convert value from a StringBuilder to a double (avoiding the String convertion, and some inner BigInt allocations for this purpose, but not all).
In Message class, I put code from the jdk to find substring in a StringBuilder too, as it was making allocations too.

Another wellknown concept I used is to cache some strings, I allocate once all the Character as strings in CharConverter class for example.

Last concept is the usage of ThreadLocal to get some reusable buffers like StringBuilder. Have to be careful to never share to other threads what is stored in a threadlocal...

Regards,



Le 5 août 2015 à 12:43, Chris Hurst <[hidden email]> a écrit :

Hi,

  Is Charles's work easily accessible for anywhere (I was just interested as I do similar work on other engines) ?   I wanted a look and I'm not that up on my GIT, though migrating soon.

Chris



From: [hidden email]
Date: Sun, 2 Aug 2015 15:53:12 +0200
To: [hidden email]; [hidden email]
Subject: Re: [Quickfixj-users] Performance latency improvement when sending messages

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Hi Charles, thanks for this. Much appreciated. I will have a closer look after my vacation. Cheers, Chris. Am 1. August 2015 09:59:50 MESZ, schrieb Charles Briquel : >QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >QuickFIX/J Support: http://www.quickfixj.org/support/ > > >Hi, > >I finished to pull request everything, I hope quick fix is quicker now >; ) > >I did not pull treeMap replacement by lists, may be one day, as an >optional behavior that we can set in the settings, if you like the >rest. >I hope it is clean enough for you, I suppose we have to put a buffer >size in settings if you take the FIXMessageEncoder change. > >In our fx environnement, we dropped from gigabytes of allocated data in >few minutes to one hundred of megabytes, we are brokers. This is not >perfect but still 10 times better. It means 10 times less minor GC if >quick fix is the only memory consumer… > >Regards, > >Charles > > >Le 24 juil. 2015 à 03:58, Christoph John a écrit : > >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support: http://www.quickfixj.org/support/ >> >> >> Hi Charles, >> >> thanks for your offer. W
Hi Charles,
thanks for this. Much appreciated. I will have a closer look after my vacation.
Cheers,
Chris.

Am 1. August 2015 09:59:50 MESZ, schrieb Charles Briquel <[hidden email]>:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

I finished to pull request everything, I hope quick fix is quicker now ; )

I did not pull treeMap replacement by lists, may be one day, as an optional behavior that we can set in the settings, if you like the rest.
I hope it is clean enough for you, I suppose we have to put a buffer size in settings if you take the FIXMessageEncoder change.

In our fx environnement, we dropped from gigabytes of allocated data in few minutes to one hundred of megabytes, we are brokers. This is not perfect but still 10 times better. It means 10 times less minor GC if quick fix is the only memory consumer…

Regards,

Charles


Le 24 juil. 2015 à 03:58, Christoph John a écrit :

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi Charles,

thanks for your offer. W

------------------------------------------------------------------------------
_______________________________________________ Quickfixj-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: Performance latency improvement when sending messages

Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi Charles,

I have taken the liberty to open a JIRA issue for the next QFJ version 1.7.0 so we have your
improvements bundled in one issue: http://www.quickfixj.org/jira/browse/QFJ-859
If you like you could register at that QFJ JIRA instance to become the assignee of that issue.

I will comment on the specific pull request later.
Thanks again for your contributions.

Cheers,
Chris.



On 05/08/15 20:04, Charles Briquel wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
>
> Hi,
>
> It should be accessible on git hub online, in the pull request section.
> Bit I don't think it's transposable to other projects, except for the CharSequenceReader class
> which is code from ths jdk to convert value from a StringBuilder to a double (avoiding the String
> convertion, and some inner BigInt allocations for this purpose, but not all).
> In Message class, I put code from the jdk to find substring in a StringBuilder too, as it was
> making allocations too.
>
> Another wellknown concept I used is to cache some strings, I allocate once all the Character as
> strings in CharConverter class for example.
>
> Last concept is the usage of ThreadLocal to get some reusable buffers like StringBuilder. Have to
> be careful to never share to other threads what is stored in a threadlocal...
>
> Regards,
>
>
>
> Le 5 août 2015 à 12:43, Chris Hurst <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Hi,
>>
>>   Is Charles's work easily accessible for anywhere (I was just interested as I do similar work on
>> other engines) ?   I wanted a look and I'm not that up on my GIT, though migrating soon.
>>
>> Chris
>>
>>
>>
>> From: [hidden email] <mailto:[hidden email]>
>> Date: Sun, 2 Aug 2015 15:53:12 +0200
>> To: [hidden email] <mailto:[hidden email]>;
>> [hidden email] <mailto:[hidden email]>
>> Subject: Re: [Quickfixj-users] Performance latency improvement when sending messages
>>
>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>  
>>  
>>
>> Hi Charles, thanks for this. Much appreciated. I will have a closer look after my vacation.
>> Cheers, Chris. Am 1. August 2015 09:59:50 MESZ, schrieb Charles Briquel : >QuickFIX/J
>> Documentation: http://www.quickfixj.org/documentation/ >QuickFIX/J Support:
>> http://www.quickfixj.org/support/ > > >Hi, > >I finished to pull request everything, I hope quick
>> fix is quicker now >; ) > >I did not pull treeMap replacement by lists, may be one day, as an
>> >optional behavior that we can set in the settings, if you like the >rest. >I hope it is clean
>> enough for you, I suppose we have to put a buffer >size in settings if you take the
>> FIXMessageEncoder change. > >In our fx environnement, we dropped from gigabytes of allocated data
>> in >few minutes to one hundred of megabytes, we are brokers. This is not >perfect but still 10
>> times better. It means 10 times less minor GC if >quick fix is the only memory consumer… >
>> >Regards, > >Charles > > >Le 24 juil. 2015 à 03:58, Christoph John a écrit : > >> QuickFIX/J
>> Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support:
>> http://www.quickfixj.org/support/ >> >> >> Hi Charles, >> >> thanks for your offer. W
>> Hi Charles,
>> thanks for this. Much appreciated. I will have a closer look after my vacation.
>> Cheers,
>> Chris.
>>
>> Am 1. August 2015 09:59:50 MESZ, schrieb Charles Briquel <[hidden email]
>> <mailto:[hidden email]>>:
>>
>>     QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>     QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>     Hi,
>>
>>     I finished to pull request everything, I hope quick fix is quicker now ; )
>>
>>     I did not pull treeMap replacement by lists, may be one day, as an optional behavior that we can set in the settings, if you like the rest.
>>     I hope it is clean enough for you, I suppose we have to put a buffer size in settings if you take the FIXMessageEncoder change.
>>
>>     In our fx environnement, we dropped from gigabytes of allocated data in few minutes to one hundred of megabytes, we are brokers. This is not perfect but still 10 times better. It means 10 times less minor GC if quick fix is the only memory consumer…
>>
>>     Regards,
>>
>>     Charles
>>
>>
>>     Le 24 juil. 2015 à 03:58, Christoph John
>>     a écrit :
>>
>>         QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support:
>>         http://www.quickfixj.org/support/ Hi Charles, thanks for your offer. W
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________ Quickfixj-users mailing list
>> [hidden email] <mailto:[hidden email]>
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email] <mailto:[hidden email]>
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

--
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:[hidden email]
       


http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
         Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: Performance latency improvement when sending messages

Charles Briquel
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi John,

This is good new.
I'm still on vacation but I will register soonly. I know there are some things to make cleaner and your comments are wellcome.
Regards,


> Le 17 août 2015 à 05:22, Christoph John <[hidden email]> a écrit :
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi Charles,
>
> I have taken the liberty to open a JIRA issue for the next QFJ version 1.7.0 so we have your
> improvements bundled in one issue: http://www.quickfixj.org/jira/browse/QFJ-859
> If you like you could register at that QFJ JIRA instance to become the assignee of that issue.
>
> I will comment on the specific pull request later.
> Thanks again for your contributions.
>
> Cheers,
> Chris.
>
>
>
>> On 05/08/15 20:04, Charles Briquel wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>>
>>
>> Hi,
>>
>> It should be accessible on git hub online, in the pull request section.
>> Bit I don't think it's transposable to other projects, except for the CharSequenceReader class
>> which is code from ths jdk to convert value from a StringBuilder to a double (avoiding the String
>> convertion, and some inner BigInt allocations for this purpose, but not all).
>> In Message class, I put code from the jdk to find substring in a StringBuilder too, as it was
>> making allocations too.
>>
>> Another wellknown concept I used is to cache some strings, I allocate once all the Character as
>> strings in CharConverter class for example.
>>
>> Last concept is the usage of ThreadLocal to get some reusable buffers like StringBuilder. Have to
>> be careful to never share to other threads what is stored in a threadlocal...
>>
>> Regards,
>>
>>
>>
>> Le 5 août 2015 à 12:43, Chris Hurst <[hidden email]
>> <mailto:[hidden email]>> a écrit :
>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>> Hi,
>>>
>>>  Is Charles's work easily accessible for anywhere (I was just interested as I do similar work on
>>> other engines) ?   I wanted a look and I'm not that up on my GIT, though migrating soon.
>>>
>>> Chris
>>>
>>>
>>>
>>> From: [hidden email] <mailto:[hidden email]>
>>> Date: Sun, 2 Aug 2015 15:53:12 +0200
>>> To: [hidden email] <mailto:[hidden email]>;
>>> [hidden email] <mailto:[hidden email]>
>>> Subject: Re: [Quickfixj-users] Performance latency improvement when sending messages
>>>
>>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>>
>>>
>>>
>>> Hi Charles, thanks for this. Much appreciated. I will have a closer look after my vacation.
>>> Cheers, Chris. Am 1. August 2015 09:59:50 MESZ, schrieb Charles Briquel : >QuickFIX/J
>>> Documentation: http://www.quickfixj.org/documentation/ >QuickFIX/J Support:
>>> http://www.quickfixj.org/support/ > > >Hi, > >I finished to pull request everything, I hope quick
>>> fix is quicker now >; ) > >I did not pull treeMap replacement by lists, may be one day, as an
>>>> optional behavior that we can set in the settings, if you like the >rest. >I hope it is clean
>>> enough for you, I suppose we have to put a buffer >size in settings if you take the
>>> FIXMessageEncoder change. > >In our fx environnement, we dropped from gigabytes of allocated data
>>> in >few minutes to one hundred of megabytes, we are brokers. This is not >perfect but still 10
>>> times better. It means 10 times less minor GC if >quick fix is the only memory consumer… >
>>>> Regards, > >Charles > > >Le 24 juil. 2015 à 03:58, Christoph John a écrit : > >> QuickFIX/J
>>> Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support:
>>> http://www.quickfixj.org/support/ >> >> >> Hi Charles, >> >> thanks for your offer. W
>>> Hi Charles,
>>> thanks for this. Much appreciated. I will have a closer look after my vacation.
>>> Cheers,
>>> Chris.
>>>
>>> Am 1. August 2015 09:59:50 MESZ, schrieb Charles Briquel <[hidden email]
>>> <mailto:[hidden email]>>:
>>>
>>>    QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>>    QuickFIX/J Support:http://www.quickfixj.org/support/
>>>
>>>
>>>    Hi,
>>>
>>>    I finished to pull request everything, I hope quick fix is quicker now ; )
>>>
>>>    I did not pull treeMap replacement by lists, may be one day, as an optional behavior that we can set in the settings, if you like the rest.
>>>    I hope it is clean enough for you, I suppose we have to put a buffer size in settings if you take the FIXMessageEncoder change.
>>>
>>>    In our fx environnement, we dropped from gigabytes of allocated data in few minutes to one hundred of megabytes, we are brokers. This is not perfect but still 10 times better. It means 10 times less minor GC if quick fix is the only memory consumer…
>>>
>>>    Regards,
>>>
>>>    Charles
>>>
>>>
>>>    Le 24 juil. 2015 à 03:58, Christoph John
>>>    a écrit :
>>>
>>>        QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support:
>>>        http://www.quickfixj.org/support/ Hi Charles, thanks for your offer. W
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________ Quickfixj-users mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Quickfixj-users mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
> --
> Christoph John
> Development & Support
> Direct: +49 241 557080-28
> Mailto:[hidden email]
>    
>
>
> http://www.macd.com <http://www.macd.com/>
> ----------------------------------------------------------------------------------------------------
>    
> ----------------------------------------------------------------------------------------------------
> MACD GmbH
> Oppenhoffallee 103
> D-52066 Aachen
> Tel: +49 241 557080-0 | Fax: +49 241 557080-10
>     Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
>
> Geschäftsführer: George Macdonald
> ----------------------------------------------------------------------------------------------------
>    
> ----------------------------------------------------------------------------------------------------
>
> take care of the environment - print only if necessary
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: Performance latency improvement when sending messages

Charles Briquel
In reply to this post by Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

I'm finally back from vacation.
I created a jira account, charlesbr1.
Can you tell me how to proceed now ?
I can checkout the 1.7.0 branch and push some changes ?

Regards,

Charles Briquel


> Le 17 août 2015 à 14:22, Christoph John <[hidden email]> a écrit :
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi Charles,
>
> I have taken the liberty to open a JIRA issue for the next QFJ version 1.7.0 so we have your
> improvements bundled in one issue: http://www.quickfixj.org/jira/browse/QFJ-859
> If you like you could register at that QFJ JIRA instance to become the assignee of that issue.
>
> I will comment on the specific pull request later.
> Thanks again for your contributions.
>
> Cheers,
> Chris.
>
>
>
>> On 05/08/15 20:04, Charles Briquel wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>>
>>
>> Hi,
>>
>> It should be accessible on git hub online, in the pull request section.
>> Bit I don't think it's transposable to other projects, except for the CharSequenceReader class
>> which is code from ths jdk to convert value from a StringBuilder to a double (avoiding the String
>> convertion, and some inner BigInt allocations for this purpose, but not all).
>> In Message class, I put code from the jdk to find substring in a StringBuilder too, as it was
>> making allocations too.
>>
>> Another wellknown concept I used is to cache some strings, I allocate once all the Character as
>> strings in CharConverter class for example.
>>
>> Last concept is the usage of ThreadLocal to get some reusable buffers like StringBuilder. Have to
>> be careful to never share to other threads what is stored in a threadlocal...
>>
>> Regards,
>>
>>
>>
>> Le 5 août 2015 à 12:43, Chris Hurst <[hidden email]
>> <mailto:[hidden email]>> a écrit :
>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>> Hi,
>>>
>>>  Is Charles's work easily accessible for anywhere (I was just interested as I do similar work on
>>> other engines) ?   I wanted a look and I'm not that up on my GIT, though migrating soon.
>>>
>>> Chris
>>>
>>>
>>>
>>> From: [hidden email] <mailto:[hidden email]>
>>> Date: Sun, 2 Aug 2015 15:53:12 +0200
>>> To: [hidden email] <mailto:[hidden email]>;
>>> [hidden email] <mailto:[hidden email]>
>>> Subject: Re: [Quickfixj-users] Performance latency improvement when sending messages
>>>
>>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>>
>>>
>>>
>>> Hi Charles, thanks for this. Much appreciated. I will have a closer look after my vacation.
>>> Cheers, Chris. Am 1. August 2015 09:59:50 MESZ, schrieb Charles Briquel : >QuickFIX/J
>>> Documentation: http://www.quickfixj.org/documentation/ >QuickFIX/J Support:
>>> http://www.quickfixj.org/support/ > > >Hi, > >I finished to pull request everything, I hope quick
>>> fix is quicker now >; ) > >I did not pull treeMap replacement by lists, may be one day, as an
>>>> optional behavior that we can set in the settings, if you like the >rest. >I hope it is clean
>>> enough for you, I suppose we have to put a buffer >size in settings if you take the
>>> FIXMessageEncoder change. > >In our fx environnement, we dropped from gigabytes of allocated data
>>> in >few minutes to one hundred of megabytes, we are brokers. This is not >perfect but still 10
>>> times better. It means 10 times less minor GC if >quick fix is the only memory consumer… >
>>>> Regards, > >Charles > > >Le 24 juil. 2015 à 03:58, Christoph John a écrit : > >> QuickFIX/J
>>> Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support:
>>> http://www.quickfixj.org/support/ >> >> >> Hi Charles, >> >> thanks for your offer. W
>>> Hi Charles,
>>> thanks for this. Much appreciated. I will have a closer look after my vacation.
>>> Cheers,
>>> Chris.
>>>
>>> Am 1. August 2015 09:59:50 MESZ, schrieb Charles Briquel <[hidden email]
>>> <mailto:[hidden email]>>:
>>>
>>>    QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>>    QuickFIX/J Support:http://www.quickfixj.org/support/
>>>
>>>
>>>    Hi,
>>>
>>>    I finished to pull request everything, I hope quick fix is quicker now ; )
>>>
>>>    I did not pull treeMap replacement by lists, may be one day, as an optional behavior that we can set in the settings, if you like the rest.
>>>    I hope it is clean enough for you, I suppose we have to put a buffer size in settings if you take the FIXMessageEncoder change.
>>>
>>>    In our fx environnement, we dropped from gigabytes of allocated data in few minutes to one hundred of megabytes, we are brokers. This is not perfect but still 10 times better. It means 10 times less minor GC if quick fix is the only memory consumer…
>>>
>>>    Regards,
>>>
>>>    Charles
>>>
>>>
>>>    Le 24 juil. 2015 à 03:58, Christoph John
>>>    a écrit :
>>>
>>>        QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support:
>>>        http://www.quickfixj.org/support/ Hi Charles, thanks for your offer. W
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________ Quickfixj-users mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Quickfixj-users mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
> --
> Christoph John
> Development & Support
> Direct: +49 241 557080-28
> Mailto:[hidden email]
>    
>
>
> http://www.macd.com <http://www.macd.com/>
> ----------------------------------------------------------------------------------------------------
>    
> ----------------------------------------------------------------------------------------------------
> MACD GmbH
> Oppenhoffallee 103
> D-52066 Aachen
> Tel: +49 241 557080-0 | Fax: +49 241 557080-10
>     Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
>
> Geschäftsführer: George Macdonald
> ----------------------------------------------------------------------------------------------------
>    
> ----------------------------------------------------------------------------------------------------
>
> take care of the environment - print only if necessary
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: Performance latency improvement when sending messages

Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Hi Charles,

sorry for getting back  so late. If it is OK for you, you could do some more PRs for the time being. I am currently quite busy and did not find the time to review all of your last PRs plus there are some other patches by other contributors that need a review.
I will try to do this within the next week and come back to you.

Sorry again and cheers,
Chris.

On 08/09/15 11:05, Charles Briquel wrote:
Hi,

I'm finally back from vacation.
I created a jira account, charlesbr1.
Can you tell me how to proceed now ?
I can checkout the 1.7.0 branch and push some changes ?

Regards,

Charles Briquel


Le 17 août 2015 à 14:22, Christoph John [hidden email] a écrit :

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi Charles,

I have taken the liberty to open a JIRA issue for the next QFJ version 1.7.0 so we have your 
improvements bundled in one issue: http://www.quickfixj.org/jira/browse/QFJ-859
If you like you could register at that QFJ JIRA instance to become the assignee of that issue.

I will comment on the specific pull request later.
Thanks again for your contributions.

Cheers,
Chris.



On 05/08/15 20:04, Charles Briquel wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




Hi,

It should be accessible on git hub online, in the pull request section.
Bit I don't think it's transposable to other projects, except for the CharSequenceReader class 
which is code from ths jdk to convert value from a StringBuilder to a double (avoiding the String 
convertion, and some inner BigInt allocations for this purpose, but not all).
In Message class, I put code from the jdk to find substring in a StringBuilder too, as it was 
making allocations too.

Another wellknown concept I used is to cache some strings, I allocate once all the Character as 
strings in CharConverter class for example.

Last concept is the usage of ThreadLocal to get some reusable buffers like StringBuilder. Have to 
be careful to never share to other threads what is stored in a threadlocal...

Regards,



Le 5 août 2015 à 12:43, Chris Hurst <[hidden email] 
[hidden email]> a écrit :

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

 Is Charles's work easily accessible for anywhere (I was just interested as I do similar work on 
other engines) ?   I wanted a look and I'm not that up on my GIT, though migrating soon.

Chris



From: [hidden email] [hidden email]
Date: Sun, 2 Aug 2015 15:53:12 +0200
To: [hidden email] [hidden email]; 
[hidden email] [hidden email]
Subject: Re: [Quickfixj-users] Performance latency improvement when sending messages

QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
QuickFIX/J Support:http://www.quickfixj.org/support/



Hi Charles, thanks for this. Much appreciated. I will have a closer look after my vacation. 
Cheers, Chris. Am 1. August 2015 09:59:50 MESZ, schrieb Charles Briquel : >QuickFIX/J 
Documentation: http://www.quickfixj.org/documentation/ >QuickFIX/J Support: 
http://www.quickfixj.org/support/ > > >Hi, > >I finished to pull request everything, I hope quick 
fix is quicker now >; ) > >I did not pull treeMap replacement by lists, may be one day, as an 
optional behavior that we can set in the settings, if you like the >rest. >I hope it is clean
enough for you, I suppose we have to put a buffer >size in settings if you take the 
FIXMessageEncoder change. > >In our fx environnement, we dropped from gigabytes of allocated data 
in >few minutes to one hundred of megabytes, we are brokers. This is not >perfect but still 10 
times better. It means 10 times less minor GC if >quick fix is the only memory consumer… > 
Regards, > >Charles > > >Le 24 juil. 2015 à 03:58, Christoph John a écrit : > >> QuickFIX/J
Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support: 
http://www.quickfixj.org/support/ >> >> >> Hi Charles, >> >> thanks for your offer. W
Hi Charles,
thanks for this. Much appreciated. I will have a closer look after my vacation.
Cheers,
Chris.

Am 1. August 2015 09:59:50 MESZ, schrieb Charles Briquel <[hidden email] 
[hidden email]>:

   QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
   QuickFIX/J Support:http://www.quickfixj.org/support/


   Hi,

   I finished to pull request everything, I hope quick fix is quicker now ; )

   I did not pull treeMap replacement by lists, may be one day, as an optional behavior that we can set in the settings, if you like the rest.
   I hope it is clean enough for you, I suppose we have to put a buffer size in settings if you take the FIXMessageEncoder change.

   In our fx environnement, we dropped from gigabytes of allocated data in few minutes to one hundred of megabytes, we are brokers. This is not perfect but still 10 times better. It means 10 times less minor GC if quick fix is the only memory consumer…

   Regards,

   Charles


   Le 24 juil. 2015 à 03:58, Christoph John
   a écrit :

       QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support:
       http://www.quickfixj.org/support/ Hi Charles, thanks for your offer. W


------------------------------------------------------------------------------
_______________________________________________ Quickfixj-users mailing list 
[hidden email] [hidden email] 
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email] [hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------


_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
-- 
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:Christoph.John@...
   


http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------
   
----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
    Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------
   
----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

--
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:Christoph.John@...



http://www.macd.com


MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
 Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald


take care of the environment - print only if necessary

------------------------------------------------------------------------------

_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users