quickfix-developers — QuickFIX developers forum

[Quickfix-developers] RES: Qt and quickfix

[Clebson D. F. P. <Cle...@cm...>]

Guys, To close this thread, be aware that QTCreator on windows uses MinGW as default compiler. So if you download MSVC version of quickfix be sure that it is using MSVC compiler as default.

-----Mensagem original-----
De: goncalvm [mailto:mar...@pa...] 
Enviada em: sexta-feira, 5 de novembro de 2010 11:44
Para: qui...@li...
Assunto: [Quickfix-developers] Qt and quickfix

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html


Hi everyone,

I would like to user quickfix and Qt, but I don't know how. I tried the c++
implementation, but I got a lot of error messages like:

config.h: No such file o directory
sys/socket.h: No such file o directory
sys/ioctl.h: No such file o directory

It seems that _MSC_VER pragma is the problem. 

Any help will be appreciated.

Thanks,

Marco

-- 
View this message in context: http://old.nabble.com/Qt-and-quickfix-tp30141253p30141253.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.


------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] RES: Qt and quickfix

[Clebson D. F. P. <Cle...@cm...>]

It doest make sense man. It shall work with QT fine. Are u able to compile quickfix ? socket.h, ioctl.h are not windows headers. It seems like u r trying to compile window version on linux.

http://www.quickfixengine.org/download.html

take a look there are different versions ;) take the right one for ya


-----Mensagem original-----
De: goncalvm [mailto:mar...@pa...] 
Enviada em: sexta-feira, 5 de novembro de 2010 11:44
Para: qui...@li...
Assunto: [Quickfix-developers] Qt and quickfix

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html


Hi everyone,

I would like to user quickfix and Qt, but I don't know how. I tried the c++
implementation, but I got a lot of error messages like:

config.h: No such file o directory
sys/socket.h: No such file o directory
sys/ioctl.h: No such file o directory

It seems that _MSC_VER pragma is the problem. 

Any help will be appreciated.

Thanks,

Marco

-- 
View this message in context: http://old.nabble.com/Qt-and-quickfix-tp30141253p30141253.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.


------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] Qt and quickfix

[goncalvm <mar...@pa...>]

Hi everyone,

I would like to user quickfix and Qt, but I don't know how. I tried the c++
implementation, but I got a lot of error messages like:

config.h: No such file o directory
sys/socket.h: No such file o directory
sys/ioctl.h: No such file o directory

It seems that _MSC_VER pragma is the problem. 

Any help will be appreciated.

Thanks,

Marco

-- 
View this message in context: http://old.nabble.com/Qt-and-quickfix-tp30141253p30141253.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

Re: [Quickfix-developers] Multiple log factories

[Kenny S. <ks...@co...>]

I don't think so, but it would be trivial to implement a logger class that
fans out it callbacks to observers.

--
Kenny Stone
Connamara Systems, LLC


On Tue, Oct 26, 2010 at 9:35 AM, Dominik Brack <dom...@gm...>wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> Hi All,
> I'm wondering if there's a way to define multiple log factories and pass it
> to the ThreadedSocketInitiator/SocketInitiator?
> I know in QuickFIX/J there's a CompositeLogFactory class that can handle
> such a situation.
> Is a similar implementation available in QuickFix?
>
> Thanks in advance!
>
> Regards,
> Dominik
>
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America
> contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
> marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] Multiple log factories

[Dominik B. <dom...@gm...>]

Hi All,
I'm wondering if there's a way to define multiple log factories and pass it
to the ThreadedSocketInitiator/SocketInitiator?
I know in QuickFIX/J there's a CompositeLogFactory class that can handle
such a situation.
Is a similar implementation available in QuickFix?

Thanks in advance!

Regards,
Dominik

Re: [Quickfix-developers] Need info on Quick Fix password encryption.

[Kenny S. <ks...@co...>]

Best example would be to look at the QuickFIX FileLog that is already in the
source tree.

--
Kenny Stone
Connamara Systems, LLC


On Mon, Oct 18, 2010 at 6:49 AM, Zuber <moh...@in...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> hi,
>
> Any updates on this??
>
> Zuber
> --
> View this message in context:
> http://old.nabble.com/Need-info-on-Quick-Fix-password-encryption.-tp29324628p29989587.html
> Sent from the QuickFIX - Dev mailing list archive at Nabble.com.
>
>
>
> ------------------------------------------------------------------------------
> Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> Flex(R) Builder(TM)) enable the development of rich applications that run
> across multiple browsers and platforms. Download your free trials today!
> http://p.sf.net/sfu/adobe-dev2dev
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Need info on Quick Fix password encryption.

[Zuber <moh...@in...>]

hi, 

Any updates on this??

Zuber
-- 
View this message in context: http://old.nabble.com/Need-info-on-Quick-Fix-password-encryption.-tp29324628p29989587.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

Re: [Quickfix-developers] checking for optional fields

[Grant B. <gbi...@co...>]

I changed your subject line, as it looks like this is a new topic.
(Furthermore, I think this is a question for the quickfix-users list,
and not quickfix-developers.  This list is for people working directly
on the QuickFIX code, not for people using it with other applications.

Anyway, I think the function you're looking for is:
bool FieldMap::isSetField (const FieldBase &field) const
(Message class is derived from FieldMap)

-Grant

On Thu, Oct 14, 2010 at 2:39 AM, mohamida <moh...@gm...> wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> What's the instruction to check the presence of optional fields in the message ?
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] QuickFix incorrectly sends Reject msg for tag 305 on SecurityDefinition msg

[mohamida <moh...@gm...>]

What's the instruction to check the presence of optional fields in the message ?

Re: [Quickfix-developers] NUnits for Quick FIX (Fails)

[Vishrant <vis...@gm...>]

Thank you guys for your quick reply.
Kenny, where is the test directory located. Can you please help me with the
pointers for the same.

Thanks, Vishrant.


On Sat, Oct 9, 2010 at 1:22 AM, Diego Frata <die...@gm...> wrote:

>  QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> NUnit spawns a new AppDomain during the test, that's reason of the crash as
> QuickFix doesn't work across AppDomains.
>
> (Unless it has been fixed in the latest releases.)
>
> Diego Frata
> die...@gm...
>
>
> On Fri, Oct 8, 2010 at 6:36 PM, Kenny Stone <ks...@co...> wrote:
>
>>  QuickFIX Documentation:
>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>>
>> QuickFIX has testing tool you can use for this (in 'test' directory).  The
>> tool acts as an initiator or acceptor and asserts message strings are sent
>> and received as expected.  It lives in the 'test' directory.  I don't see
>> why nunit shouldn't work as well, just pointing out there is another
>> solution.
>>
>> --
>> Kenny Stone
>> Connamara Systems, LLC
>>
>>
>> On Fri, Oct 8, 2010 at 10:12 AM, Vishrant <vis...@gm...> wrote:
>>
>>> QuickFIX Documentation:
>>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>>
>>>
>>> Hello All,
>>> I have build an Initiator to test my Acceptor. But i want to check the
>>> correctness of messages for eg. if i send LOGON message then i want to see
>>> whether the response message is expected message. But i want to this
>>> automated. So, i tried writing NUnits for the same. But, when i try to test
>>> using Nunit exe and load my project, the Nunit exe shuts down and closes
>>> unexpectedly. So, I was wondering whether it is possible to write Nunits for
>>> FIX if not what is the best possible way to test Request and Response
>>> messages.
>>>
>>> One way i thought was to compare the response and expected message using
>>> "String Compairson" functions.
>>>
>>> If any one of you know about this scenario or have faced the same problem
>>> please help me. As this would save my time and also i can concentrate on
>>> this which are workable.
>>>
>>>
>>> --
>>> Regards
>>> Vishrant Shah.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Beautiful is writing same markup. Internet Explorer 9 supports
>>> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
>>> Spend less time writing and  rewriting code and more time creating great
>>> experiences on the web. Be a part of the beta today.
>>> http://p.sf.net/sfu/beautyoftheweb
>>> _______________________________________________
>>> Quickfix-developers mailing list
>>> Qui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Beautiful is writing same markup. Internet Explorer 9 supports
>> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
>> Spend less time writing and  rewriting code and more time creating great
>> experiences on the web. Be a part of the beta today.
>> http://p.sf.net/sfu/beautyoftheweb
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>



-- 
--
Regards
Vishrant Shah.

Re: [Quickfix-developers] NUnits for Quick FIX (Fails)

[Diego F. <die...@gm...>]

NUnit spawns a new AppDomain during the test, that's reason of the crash as
QuickFix doesn't work across AppDomains.

(Unless it has been fixed in the latest releases.)

Diego Frata
die...@gm...


On Fri, Oct 8, 2010 at 6:36 PM, Kenny Stone <ks...@co...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> QuickFIX has testing tool you can use for this (in 'test' directory).  The
> tool acts as an initiator or acceptor and asserts message strings are sent
> and received as expected.  It lives in the 'test' directory.  I don't see
> why nunit shouldn't work as well, just pointing out there is another
> solution.
>
> --
> Kenny Stone
> Connamara Systems, LLC
>
>
> On Fri, Oct 8, 2010 at 10:12 AM, Vishrant <vis...@gm...> wrote:
>
>> QuickFIX Documentation:
>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>>
>> Hello All,
>> I have build an Initiator to test my Acceptor. But i want to check the
>> correctness of messages for eg. if i send LOGON message then i want to see
>> whether the response message is expected message. But i want to this
>> automated. So, i tried writing NUnits for the same. But, when i try to test
>> using Nunit exe and load my project, the Nunit exe shuts down and closes
>> unexpectedly. So, I was wondering whether it is possible to write Nunits for
>> FIX if not what is the best possible way to test Request and Response
>> messages.
>>
>> One way i thought was to compare the response and expected message using
>> "String Compairson" functions.
>>
>> If any one of you know about this scenario or have faced the same problem
>> please help me. As this would save my time and also i can concentrate on
>> this which are workable.
>>
>>
>> --
>> Regards
>> Vishrant Shah.
>>
>>
>> ------------------------------------------------------------------------------
>> Beautiful is writing same markup. Internet Explorer 9 supports
>> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
>> Spend less time writing and  rewriting code and more time creating great
>> experiences on the web. Be a part of the beta today.
>> http://p.sf.net/sfu/beautyoftheweb
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] NUnits for Quick FIX (Fails)

[Kenny S. <ks...@co...>]

QuickFIX has testing tool you can use for this (in 'test' directory).  The
tool acts as an initiator or acceptor and asserts message strings are sent
and received as expected.  It lives in the 'test' directory.  I don't see
why nunit shouldn't work as well, just pointing out there is another
solution.

--
Kenny Stone
Connamara Systems, LLC


On Fri, Oct 8, 2010 at 10:12 AM, Vishrant <vis...@gm...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> Hello All,
> I have build an Initiator to test my Acceptor. But i want to check the
> correctness of messages for eg. if i send LOGON message then i want to see
> whether the response message is expected message. But i want to this
> automated. So, i tried writing NUnits for the same. But, when i try to test
> using Nunit exe and load my project, the Nunit exe shuts down and closes
> unexpectedly. So, I was wondering whether it is possible to write Nunits for
> FIX if not what is the best possible way to test Request and Response
> messages.
>
> One way i thought was to compare the response and expected message using
> "String Compairson" functions.
>
> If any one of you know about this scenario or have faced the same problem
> please help me. As this would save my time and also i can concentrate on
> this which are workable.
>
>
> --
> Regards
> Vishrant Shah.
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] NUnits for Quick FIX (Fails)

[Vishrant <vis...@gm...>]

Hello All,
I have build an Initiator to test my Acceptor. But i want to check the
correctness of messages for eg. if i send LOGON message then i want to see
whether the response message is expected message. But i want to this
automated. So, i tried writing NUnits for the same. But, when i try to test
using Nunit exe and load my project, the Nunit exe shuts down and closes
unexpectedly. So, I was wondering whether it is possible to write Nunits for
FIX if not what is the best possible way to test Request and Response
messages.

One way i thought was to compare the response and expected message using
"String Compairson" functions.

If any one of you know about this scenario or have faced the same problem
please help me. As this would save my time and also i can concentrate on
this which are workable.


--
Regards
Vishrant Shah.

Re: [Quickfix-developers] Need info on Quick Fix password encryption.

[Zuber <moh...@in...>]

Draupnir , thanks for you reply. I tried implmenting your idea but now all
the logs are getting blocked. If you could provide my with a small code
snippet it would be quite a help.

Looking fwd to your reply.

Thanks 
Zuber
-- 
View this message in context: http://old.nabble.com/Need-info-on-Quick-Fix-password-encryption.-tp29324628p29914382.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

[Quickfix-developers] Open File Leakage -- Quick Fix

[Daniel M. <dmo...@ya...>]

I have a process on Linux that starts and configures Fix Connections --

I have realized while the connection is running, some of the sockets do not 
clear -- 
The effect is that after a while the process runs out of open file descriptors 
and I can not
accept any more corrections.

Has any one seen this -- I get the following message when I do lsof -p 552 
(processid)

order_ser 552 dmouness  329u  sock     0,4          1231625 can't identify 
protocol
order_ser 552 dmouness  330u  sock     0,4          1231626 can't identify 
protocol
order_ser 552 dmouness  331u  sock     0,4          1231627 can't identify 
protocol
order_ser 552 dmouness  332u  sock     0,4          1231630 can't identify 
protocol
order_ser 552 dmouness  333u  sock     0,4          1231631 can't identify 
protocol



      

Re: [Quickfix-developers] Fast message cloning, toString() setString()?

[Dale W. <wi...@oc...>]

  Hi Wil,
I know you asked about C#.  Let me answer the question for C++ and see 
if that helps.

By FAR the fastest way to clone a message in C++ is:
    FIX::Message newMessage(originalMessage);

that is to use the copy constructor to initialize an auto variable.  
Note that there is no need to render the object into a string; no need 
for a data dictionary; and in C++ no need for heap allocation of the 
message object itself (allocation consists of bumping the stack pointer 
by sizeof(Message).   Some of the contents may require heap allocation, 
but there's not a good, safe way around that.

The equivalent code in C#

    FIX.Message newMessage = new FIX.Message(originalMessage);

does require a heap allocation -- but then EVERYTHING in C# requires a 
heap allocation [yes, I know I'm exaggerating] so the .NET heap 
allocator/garbage collector is highly optimized to make this as painless 
as possible.    Notice that in your technique of rendering the message 
to string then parsing the string into a new message you are using a 
heap allocated string!

If I were writing the code and performance was critical, I'd go with the 
above technique then profile the code to see if more arcane techniques 
were indicated.   If they were, I would be very sure to profile the 
results to be sure that any optimization I came up with didn't slow the 
system down too badly (grin)

Dale






On 10/4/2010 12:15 PM, Wilhelm Thomas wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>
> Hello, I'm using c#
> I'm basically trying to clone super fast a message without having the 
> need to create a new Message everytime but just feeding the new string 
> via setString.
> Unfortunatly string msg = message.Tostring() doesn't seem to output 
> the tag in the right order, so I can not do
> another_message.setstring(@msg)
> What is the fastest way to get the string out from a Message object so 
> I can feed an empty Message object?
> Any other idea for a super fast cloning not involving the creation of 
> too many objects?
> thanks for your help
> Wil
>
>
> ------------------------------------------------------------------------------
> Virtualization is moving to the mainstream and overtaking non-virtualized
> environment for deploying applications. Does it make network security
> easier or more difficult to achieve? Read this whitepaper to separate the
> two and get a better understanding.
> http://p.sf.net/sfu/hp-phase2-d2d
>
>
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] RES: Fast message cloning, toString() setString()?

[Thiago H. C. <thi...@it...>]

Have you tried this one:

	void setString(string @string, bool validate, DataDictionary dataDictionary);

Passing the same DataDictionary from source message may solve the field order problem you're having.

Regards,
Thiago


-----Mensagem original-----
De: Wilhelm Thomas [mailto:th...@cu...] 
Enviada em: segunda-feira, 4 de outubro de 2010 14:16
Para: qui...@li...
Assunto: [Quickfix-developers] Fast message cloning, toString() setString()?

Hello, I'm using c#
I'm basically trying to clone super fast a message without having the need
to create a new Message everytime but just feeding the new string via
setString.

Unfortunatly string msg = message.Tostring() doesn't seem to output the tag
in the right order, so I can not do
another_message.setstring(@msg)

What is the fastest way to get the string out from a Message object so I can
feed an empty Message object?
Any other idea for a super fast cloning not involving the creation of too
many objects?

thanks for your help
Wil

[Quickfix-developers] Fast message cloning, toString() setString()?

[Wilhelm T. <th...@cu...>]

Hello, I'm using c#
I'm basically trying to clone super fast a message without having the need
to create a new Message everytime but just feeding the new string via
setString.

Unfortunatly string msg = message.Tostring() doesn't seem to output the tag
in the right order, so I can not do
another_message.setstring(@msg)

What is the fastest way to get the string out from a Message object so I can
feed an empty Message object?
Any other idea for a super fast cloning not involving the creation of too
many objects?

thanks for your help
Wil

Re: [Quickfix-developers] [Quickfix-users] Performance

[Kenny S. <ks...@co...>]

I beliebe CheckLatency will require a timestamp for every incoming message,
so that could be expensive.

--
Kenny Stone
Connamara Systems, LLC


On Wed, Sep 22, 2010 at 3:34 PM, Wilhelm Thomas <th...@cu...>wrote:

> Thanks
>
> I have the following for validation
>
> *# Validation*
> *ValidateFieldsOutOfOrder=N*
> *ValidateFieldsHaveValues=N*
> *ValidateUserDefinedFields=N*
> *CheckCompID=N*
> *CheckLatency=Y*
> *MaxLatency=120*
> *UseDataDictionary=Y*
> *DataDictionary=.....*
>
>
> I will guess this is optimum (I guess the CheckLatency is cheap and we
> can't do without the UseDataDictionary if we have groups....)
> Let me know if any other idea -thanks.
>
> What throughput (nb of messages) are you able to achieve with QF? I use c#
> Has anyone been able to use SendBufferSize and ReceiveBufferSize, I set
> them to
> SendBufferSize=10000
> ReceiveBufferSize=10000
> But I'm not sure what values to put to see a difference?
>
> Thanks for your help
>
> Wil
>
>
>
>
> On Wed, Sep 22, 2010 at 11:31 AM, Kenny Stone <ks...@co...>wrote:
>
>> There are a number of validation tunings you can set in the config file
>> that will have some impact on performance (less validation == faster)
>>
>> http://quickfixengine.org/quickfix/doc/html/configuration.html
>>
>> Data dictionary is required for parsing repeating groups.
>>
>> --
>> Kenny Stone
>> Connamara Systems, LLC
>>
>>
>> On Wed, Sep 22, 2010 at 12:54 PM, Wilhelm Thomas <th...@cu...>wrote:
>>
>>> QuickFIX Documentation:
>>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>>
>>>
>>> Hello
>>>
>>> On the performance side here are some numbers, not really comparing 2
>>> version but just showing where the time is spent....
>>>
>>> setString, setField and their get counter part seem pretty slow:
>>>
>>> *Downward trace*
>>> *100.00 % setString - 66862* ms - 1443841 calls -
>>> QuickFix.Message.setString(Int32, String)*
>>> *  97.76 % mapSetString - 65364* ms - 1443841 calls -
>>> .mapSetString(Int32, String, FieldMap *)   (from QuickFix)*
>>> *    50.51 % convertString - 33774* ms - 1443841 calls -
>>> .convertString(basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > *, String)   (from QuickFix)*
>>> *      16.75 %** Compare - 11201 ms **- 1443841 calls -
>>> System.String.Compare(String, String)*
>>> *      12.81 % createUnmanagedString - 8564 ms - 1443841 calls -
>>> .createUnmanagedString(String)   (from QuickFix)*
>>> *        10.10 %** StringToHGlobalAnsi - 6755 ms -** 1443841 calls -
>>> System.Runtime.InteropServices.Marshal.StringToHGlobalAnsi(String)*
>>> *      6.16 % FreeHGlobal - 4118 ms - 1443841 calls -
>>> System.Runtime.InteropServices.Marshal.FreeHGlobal(IntPtr)*
>>> *      1.91 % {ctor} - 1279 ms - 1443841 calls -
>>> .{ctor}(basic_string<char, std::char_traits<char>, std::allocator<char> > *,
>>> SByte *)   (from
>>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>>> *      1.84 % {ctor} - 1232 ms - 1443840 calls -
>>> .{ctor}(basic_string<char, std::char_traits<char>, std::allocator<char> > *,
>>> basic_string<char, std::char_traits<char>, std::allocator<char> > *)   (from
>>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>>> *      1.77 % {dtor}* - 1186 ms - 1443840 calls -
>>> .{dtor}*(basic_string<char, std::char_traits<char>, std::allocator<char> >
>>> *)   (from std.basic_string<char,std::char_traits<char>,std::allocator<char>
>>> >)*
>>> *    28.02 % setField - 18736 ms - 1443840 calls - .setField(FieldMap *,
>>> FieldBase *, Boolean)   (from FIX.FieldMap)*
>>> *      16.82 % find - 11248 ms - 1443840 calls -
>>> .find(_Tree<std::_Tmap_traits<int, FIX::FieldBase, FIX::message_order,
>>> std::allocator<std::pair<int const, FIX::FieldBase> >, 1> > *, iterator *,
>>> Int32 *)   (from
>>> std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,std::allocator<std::pair<int
>>> const ,FIX::FieldBase> >,1> >)*
>>> *        11.85 % _Lbound - 7925 ms - 1443840 calls -
>>> ._Lbound(_Tree<std::_Tmap_traits<int, FIX::FieldBase, FIX::message_order,
>>> std::allocator<std::pair<int const, FIX::FieldBase> >, 1> > *, Int32 *)
>>> (from
>>> std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,std::allocator<std::pair<int
>>> const ,FIX::FieldBase> >,1> >)*
>>> *          5.76 % () - 3853 ms - 5775360 calls - .()(message_order *,
>>> Int32 *, Int32 *)   (from FIX.message_order)*
>>> *        1.40 % () - 936 ms - 1443840 calls - .()(message_order *, Int32
>>> *, Int32 *)   (from FIX.message_order)*
>>> *      7.47 % = - 4992 ms - 1443840 calls - .=(FieldBase *, FieldBase *)
>>>   (from FIX.FieldBase)*
>>> *        2.87 % =* - 1919 ms - 2887680 calls - .=*(basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > *, basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > *)   (from
>>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>>> *    4.57 % {dtor}* - 3058 ms - 4331520 calls -
>>> .{dtor}*(basic_string<char, std::char_traits<char>, std::allocator<char> >
>>> *)   (from std.basic_string<char,std::char_traits<char>,std::allocator<char>
>>> >)*
>>> *    1.61 % {ctor} - 1076 ms - 1443840 calls -
>>> .{ctor}(basic_string<char, std::char_traits<char>, std::allocator<char> > *)
>>>   (from std.basic_string<char,std::char_traits<char>,std::allocator<char> >)
>>> *
>>> *    1.49 % {ctor} - 998 ms - 1443840 calls - .{ctor}(basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > *, basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > *)   (from
>>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>>>
>>>
>>> *Downward trace*
>>> *100.00 % **setField** - 18439 ms - 393141 calls -
>>> QuickFix.Message.setField(Int32, String)*
>>> *  97.29 % mapSetField - 17940 ms - 393141 calls - .mapSetField(Int32,
>>> String, FieldMap *)   (from QuickFix)*
>>> *    50.25 % convertString - 9266 ms - 393141 calls -
>>> .convertString(basic_string<char, std::char_traits<char>,
>>> std::allocator<char> > *, String)   (from QuickFix)*
>>> *      18.36 % Compare - 3385 ms - 393141 calls -
>>> System.String.Compare(String, String)*
>>> *      10.74 % createUnmanagedString - 1981 ms - 393141 calls -
>>> .createUnmanagedString(String)   (from QuickFix)*
>>> *        7.61 % StringToHGlobalAnsi - 1404 ms - 393141 calls -
>>> System.Runtime.InteropServices.Marshal.StringToHGlobalAnsi(String)*
>>> *      7.70 % FreeHGlobal - 1420 ms - 393141 calls -
>>> System.Runtime.InteropServices.Marshal.FreeHGlobal(IntPtr)*
>>> *      1.78 % {ctor} - 328 ms - 393141 calls -
>>> .{ctor}(basic_string<char, std::char_traits<char>, std::allocator<char> > *,
>>> basic_string<char, std::char_traits<char>, std::allocator<char> > *)   (from
>>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>>> *      1.69 % {ctor} - 312 ms - 393141 calls -
>>> .{ctor}(basic_string<char, std::char_traits<char>, std::allocator<char> > *,
>>> SByte *)   (from
>>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>>> *      0.93 % {dtor}* - 172 ms - 393141 calls -
>>> .{dtor}*(basic_string<char, std::char_traits<char>, std::allocator<char> >
>>> *)   (from std.basic_string<char,std::char_traits<char>,std::allocator<char>
>>> >)*
>>> *    40.69 % setField - 7504 ms - 393141 calls - .setField(FieldMap *,
>>> Int32, basic_string<char, std::char_traits<char>, std::allocator<char> > *)
>>>   (from FIX.FieldMap)*
>>> *      25.63 % setField - 4727 ms - 393141 calls - .setField(FieldMap *,
>>> FieldBase *, Boolean)   (from FIX.FieldMap)*
>>> *        14.97 % find - 2761 ms - 393141 calls -
>>> .find(_Tree<std::_Tmap_traits<int, FIX::FieldBase, FIX::message_order,
>>> std::allocator<std::pair<int const, FIX::FieldBase> >, 1> > *, iterator *,
>>> Int32 *)   (from
>>> std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,std::allocator<std::pair<int
>>> const ,FIX::FieldBase> >,1> >)*
>>> *          10.49 % _Lbound - 1934 ms - 393141 calls -
>>> ._Lbound(_Tree<std::_Tmap_traits<int, FIX::FieldBase, FIX::message_order,
>>> std::allocator<std::pair<int const, FIX::FieldBase> >, 1> > *, Int32 *)
>>> (from
>>> std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,std::allocator<std::pair<int
>>> const ,FIX::FieldBase> >,1> >)*
>>> *          1.02 % () - 187 ms - 393141 calls - .()(message_order *,
>>> Int32 *, Int32 *)   (from FIX.message_order)*
>>> *        7.02 % = - 1295 ms - 393141 calls - .=(FieldBase *, FieldBase
>>> *)   (from FIX.FieldBase)*
>>> *          2.45 % =* - 452 ms - 786282 calls - .=*(basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > *, basic_string<char,
>>> std::char_traits<char>, std::allocator<char> > *)   (from
>>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>>> *      3.05 % {dtor}* - 562 ms - 786282 calls -
>>> .{dtor}*(basic_string<char, std::char_traits<char>, std::allocator<char> >
>>> *)   (from std.basic_string<char,std::char_traits<char>,std::allocator<char>
>>> >)*
>>> *      1.61 % {ctor} - 296 ms - 393141 calls -
>>> .{ctor}(basic_string<char, std::char_traits<char>, std::allocator<char> > *,
>>> basic_string<char, std::char_traits<char>, std::allocator<char> > *)   (from
>>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>>> *      1.61 % {ctor} - 296 ms - 393141 calls -
>>> .{ctor}(basic_string<char, std::char_traits<char>, std::allocator<char> > *)
>>>   (from std.basic_string<char,std::char_traits<char>,std::allocator<char> >)
>>> *
>>> *    0.76 % {dtor}* - 140 ms - 393141 calls -
>>> .{dtor}*(basic_string<char, std::char_traits<char>, std::allocator<char> >
>>> *)   (from std.basic_string<char,std::char_traits<char>,std::allocator<char>
>>> >)*
>>>
>>>
>>> The destructor also, may be there is a way to use a pool of messages
>>> instead of really disposing them?
>>> *
>>> *
>>> *Upward trace*
>>> *6.89 % {**dtor**}* - 19266 ms - 796435 calls - .{dtor}*(FieldMap *)
>>> (from FIX.FieldMap)*
>>> *  4.64 % __vecDelDtor - 12979 of 19266 ms - 443321 of 796435 calls -
>>> .__vecDelDtor(FieldMap *, UInt32)   (from FIX.FieldMap)*
>>> *    2.61 % {dtor}* - 7301 of 19266 ms - 221660 of 796435 calls -
>>> .{dtor}*(FieldMap *)   (from FIX.FieldMap)*
>>> *      2.61 % {dtor} - 7301 of 19266 ms - 221660 of 796435 calls -
>>> .{dtor}(Message *)   (from FIX.Message)*
>>> *        2.61 % __vecDelDtor - 7301 of 19266 ms - 221660 of 796435 calls
>>> - .__vecDelDtor(Message *, UInt32)   (from FIX.Message)*
>>> *          2.61 % ?function?* - 7301 of 19266 ms - 221660 of 796435
>>> calls - ?class?.?function?*(?parameters?)*
>>> *            2.61 % **Dispose **- 7301 of 19266 ms - 221660 of 796435
>>> calls - QuickFix.Message.Dispose()*
>>> *              1.70 % Finalize - 4742 of 19266 ms - 111139 of 796435
>>> calls - QuickFix.Message.Finalize()*
>>> *              0.91 % fromApp - 2558 of 19266 ms - 110457 of 796435
>>> calls - POLR.Gateway.Application_Initiator.fromApp(Message, SessionID)*
>>> *              0.00 % DisconnectInstrumentIfNeeded - 0 of 19266 ms - 16
>>> of 796435 calls - POLR.Gateway.PG_Util.DisconnectInstrumentIfNeeded(Message,
>>> InstrumentID)*
>>> *              0.00 % AcceptorFromApp_InitiatorToApp - 0 of 19266 ms -
>>> 48 of 796435 calls -
>>> POLR.Gateway.Application_Acceptor.AcceptorFromApp_InitiatorToApp(Message,
>>> SessionID)*
>>> *    0.96 % =* - 2699 of 19266 ms - 111140 of 796435 calls -
>>> .=*(FieldMap *, FieldMap *)   (from FIX.FieldMap)*
>>> *    0.76 % Thread #6673184 - 2137 of 19266 ms - 76059 of 796435 calls*
>>> *    0.09 % Thread #6646824 - 250 of 19266 ms - 13712 of 796435 calls*
>>> *    0.00 % Thread #6648528 - 0 of 19266 ms - 24 of 796435 calls*
>>> *  1.40 % {dtor} - 3916 of 19266 ms - 242571 of 796435 calls -
>>> .{dtor}(Message *)   (from FIX.Message)*
>>> *  0.85 % {dtor} - 2371 of 19266 ms - 110543 of 796435 calls -
>>> .{dtor}(Group *)   (from FIX.Group)*
>>>
>>>
>>> (please do not compare the timeframe in those 2 subtrees, just look at
>>> what functions cost a lot)
>>> Something to note from other tests setString is faster than setField but
>>> getField is way faster than getString
>>> I there faster other functions that I could use? thanks
>>>
>>>
>>> Here is another one very expensive
>>> *UpwardTrace*
>>> *37.22 % **=*** - 104131 ms - 364156 calls - .=*(FieldMap *, FieldMap *)
>>>   (from FIX.FieldMap)*
>>> *  37.22 % = - 104131 of 104131 ms - 364134 of 364156 calls - .=(Message
>>> *, Message *)   (from FIX.Message)*
>>> *    25.48 % **setUnmanaged **- 71277 of 104131 ms - 242568 of 364156
>>> calls - QuickFix.Message.setUnmanaged(Message *)*
>>> *      25.48 % create - 71277 of 104131 ms - 242568 of 364156 calls -
>>> .create(Application *, Message *)   (from Application)*
>>> *        12.85 % toApp - 35958 of 104131 ms - 118278 of 364156 calls -
>>> .toApp(Application *, Message *, SessionID *)   (from Application)*
>>> *          12.85 % sendToTarget* - 35958 of 104131 ms - 118278 of 364156
>>> calls - .sendToTarget*(Message *, SenderCompID *, TargetCompID *,
>>> basic_string<char, std::char_traits<char>, std::allocator<char> > *)   (from
>>> FIX.Session)*
>>> *            12.85 % sendToTarget - 35958 of 104131 ms - 118278 of
>>> 364156 calls - QuickFix.Session.sendToTarget(Message, String, String)*
>>> *              12.83 % InitiatorFromApp_AcceptorToApp - 35896 of 104131
>>> ms - 117762 of 364156 calls -
>>> POLR.Gateway.Application_Initiator.InitiatorFromApp_AcceptorToApp(Message,
>>> SessionID)*
>>> *              0.02 % onLogon - 47 of 104131 ms - 480 of 364156 calls -
>>> POLR.Gateway.Application_Initiator.onLogon(SessionID)*
>>> *              0.01 % AcceptorFromApp_InitiatorToApp - 16 of 104131 ms -
>>> 27 of 364156 calls -
>>> POLR.Gateway.Application_Acceptor.AcceptorFromApp_InitiatorToApp(Message,
>>> SessionID)*
>>> *              0.00 % ReconnectToInstrumentsFeed - 0 of 104131 ms - 3 of
>>> 364156 calls - POLR.Gateway.PG_Util.ReconnectToInstrumentsFeed()*
>>> *              0.00 % DisconnectInstrumentIfNeeded - 0 of 104131 ms - 6
>>> of 364156 calls - POLR.Gateway.PG_Util.DisconnectInstrumentIfNeeded(Message,
>>> InstrumentID)*
>>> *        12.59 % fromApp - 35209 of 104131 ms - 117813 of 364156 calls -
>>> .fromApp(Application *, Message *, SessionID *)   (from Application)*
>>> *        0.02 % toAdmin - 62 of 104131 ms - 3288 of 364156 calls -
>>> .toAdmin(Application *, Message *, SessionID *)   (from Application)*
>>> *        0.02 % fromAdmin - 47 of 104131 ms - 3189 of 364156 calls -
>>> .fromAdmin(Application *, Message *, SessionID *)   (from Application)*
>>> *    11.73 % toApp - 32823 of 104131 ms - 118278 of 364156 calls -
>>> .toApp(Application *, Message *, SessionID *)   (from Application)*
>>> *    0.01 % toAdmin - 31 of 104131 ms - 3288 of 364156 calls -
>>> .toAdmin(Application *, Message *, SessionID *)   (from Application)*
>>> *  0.00 % getGroup - 0 of 104131 ms - 22 of 364156 calls -
>>> .getGroup(FieldMap *, Int32, Int32, FieldMap *)   (from FIX.FieldMap)*
>>>
>>> Here is a set from a long test of the function that take most of the time
>>>
>>>    1. *FieldMap * .=*(FieldMap *, FieldMap *)   (from FIX.FieldMap)*
>>>    2. *message_order * .=*(message_order *, message_order *)   (from
>>>    FIX.message_order)*
>>>    3. *Void .delete[]*(Void *)*
>>>    4. *Void ._Adopt(_Iterator_base *, _Container_base_secure *)   (from
>>>    std._Iterator_base)*
>>>    5. *Void .{dtor}*(FieldMap *)   (from FIX.FieldMap)*
>>>    6. *Message .create(Application *, Message *)   (from Application)*
>>>    7. *Group QuickFix.Message.getGroup(UInt32, Group)*
>>>    8. *String QuickFix.Group.getField(Int32)*
>>>    9. *MDEntrySize
>>>    QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDEntrySize()*
>>>    10. *MDEntryPx
>>>    QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDEntryPx()*
>>>    11. *MDEntryType
>>>    QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDEntryType()*
>>>    12. *NoMDEntries
>>>    QuickFix42.MarketDataIncrementalRefresh.getNoMDEntries()*
>>>    13. *MDEntryPositionNo
>>>    QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDEntryPositionNo()
>>>    *
>>>    14. *MDUpdateAction
>>>    QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDUpdateAction()
>>>    *
>>>    15. *Void QuickFix42.MarketDataIncrementalRefresh.NoMDEntries..ctor()
>>>    *
>>>    16. *UtcTimeStamp * .getCreationTime(MessageStore *, UtcTimeStamp *)
>>>      (from MessageStore)*
>>>    17. *MDReqID QuickFix42.MarketDataIncrementalRefresh.getMDReqID()*
>>>    18. *Boolean
>>>    QuickFix42.MarketDataIncrementalRefresh.isSetNoMDEntries()*
>>>    19. *Void System.Windows.Forms.TextBoxBase.AppendText(String)*
>>>    20. *Object System.Delegate.DynamicInvokeImpl(Object [])*
>>>
>>>
>>>
>>> Something else:
>>> Is there a way to totally disable the Dictionary check even with
>>> repeating group, like I have 2 machines that I control, I already run them
>>> with the dictionary enable and everything is fine, now I want to run them
>>> without the dictionary check as I know those machines won't change.....
>>>
>>> Thanks
>>>
>>> Wil
>>>
>>> On Wed, Jun 23, 2010 at 5:48 PM, Hei Chan <str...@ya...>wrote:
>>>
>>>> QuickFIX Documentation:
>>>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>>>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>>>
>>>> Hi,
>>>>
>>>> I just wonder whether anyone has compared the performance of the latest
>>>> quickfix/C++ 1.13.3 with 1.12.4.
>>>>
>>>> With 1.12.4 (with a small modification -- added support to set send
>>>> buffer size), it seems to be faster than 1.13.3 during my ping test:
>>>> - A server logs the timestamp and sends me a "ping" FIX message.
>>>> - My server replies and the server logs the timestamp when it receives
>>>> my reply.
>>>>
>>>> The ping time increased from 2.2275ms to 2.65833ms out of 120 pings
>>>> within an hour.
>>>>
>>>> Although I understand that it is not a very accurate measure (since the
>>>> time isn't logged in microsecond and # of samples are few), it roughly
>>>> indicates some performance degradation.
>>>>
>>>> I am not saying that there must be a performance degradation...
>>>>
>>>> But I am curious whether anyone on the list can share some stats...
>>>>
>>>> Thanks in advance.
>>>>
>>>>
>>>> Cheers,
>>>> Hei
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>> lucky parental unit.  See the prize list and enter to win:
>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>> _______________________________________________
>>>> Quickfix-users mailing list
>>>> Qui...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Start uncovering the many advantages of virtual appliances
>>> and start using them to simplify application deployment and
>>> accelerate your shift to cloud computing.
>>> http://p.sf.net/sfu/novell-sfdev2dev
>>> _______________________________________________
>>> Quickfix-developers mailing list
>>> Qui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>>
>>
>>
>

[Quickfix-developers] Message type n for QuickFIXJ

[Angel R. <la...@sp...>]

Hi, 

I am trying to  use  messages type "n" in QuickFIX for Java, because I need
to send a FIXML over FIX 4.4 but, when the FIX Engine Aceptor recived the
message, it respond a MessageReject  message whit  ^35=3^ . ^58=Invalid
MsgType^372=n^373=11^.  I check my FIX message and think that all is right.

 

Does QuickFixJ support messages type "n"?

Anybody know how is the correct way for resolve this in QuickFix for Java?

 

This is the FIX message

 

8=FIX.4.4^9=394^35=n^34=588^49=quote.ICAM^52=20100825-22:02:35.556^56=demo.f
xgrid^212=315^213=<FIXML><PosMntReq ReqID="1" TxnTyp="3" Act

n="1" BizDt="2009-09-10" SetSesID="ITD" TxnTm="2009-09-10T00:00:00" ><Pty
Mnemonico="ACCI" Tipo="T" ID="10215" R="7"><PtySub ID="CW00"
Type="11"/></Pty><Amt Typ="CAS

H-DEBITO"  Amt="125,000"  Ccy="MXP"/><Amt Typ="MERCADO-CREDITO" Amt="10,000"
Ccy="MXP"/></PosMntReq></FIXML>^10=141^

 

 

Thanks in advance.

Angel R.

 

Re: [Quickfix-developers] [Quickfix-users] Performance

[Wilhelm T. <th...@cu...>]

Thanks

I have the following for validation

*# Validation*
*ValidateFieldsOutOfOrder=N*
*ValidateFieldsHaveValues=N*
*ValidateUserDefinedFields=N*
*CheckCompID=N*
*CheckLatency=Y*
*MaxLatency=120*
*UseDataDictionary=Y*
*DataDictionary=.....*


I will guess this is optimum (I guess the CheckLatency is cheap and we can't
do without the UseDataDictionary if we have groups....)
Let me know if any other idea -thanks.

What throughput (nb of messages) are you able to achieve with QF? I use c#
Has anyone been able to use SendBufferSize and ReceiveBufferSize, I set them
to
SendBufferSize=10000
ReceiveBufferSize=10000
But I'm not sure what values to put to see a difference?

Thanks for your help

Wil




On Wed, Sep 22, 2010 at 11:31 AM, Kenny Stone <ks...@co...> wrote:

> There are a number of validation tunings you can set in the config file
> that will have some impact on performance (less validation == faster)
>
> http://quickfixengine.org/quickfix/doc/html/configuration.html
>
> Data dictionary is required for parsing repeating groups.
>
> --
> Kenny Stone
> Connamara Systems, LLC
>
>
> On Wed, Sep 22, 2010 at 12:54 PM, Wilhelm Thomas <th...@cu...>wrote:
>
>> QuickFIX Documentation:
>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>>
>> Hello
>>
>> On the performance side here are some numbers, not really comparing 2
>> version but just showing where the time is spent....
>>
>> setString, setField and their get counter part seem pretty slow:
>>
>> *Downward trace*
>> *100.00 % setString - 66862* ms - 1443841 calls -
>> QuickFix.Message.setString(Int32, String)*
>> *  97.76 % mapSetString - 65364* ms - 1443841 calls -
>> .mapSetString(Int32, String, FieldMap *)   (from QuickFix)*
>> *    50.51 % convertString - 33774* ms - 1443841 calls -
>> .convertString(basic_string<char, std::char_traits<char>,
>> std::allocator<char> > *, String)   (from QuickFix)*
>> *      16.75 %** Compare - 11201 ms **- 1443841 calls -
>> System.String.Compare(String, String)*
>> *      12.81 % createUnmanagedString - 8564 ms - 1443841 calls -
>> .createUnmanagedString(String)   (from QuickFix)*
>> *        10.10 %** StringToHGlobalAnsi - 6755 ms -** 1443841 calls -
>> System.Runtime.InteropServices.Marshal.StringToHGlobalAnsi(String)*
>> *      6.16 % FreeHGlobal - 4118 ms - 1443841 calls -
>> System.Runtime.InteropServices.Marshal.FreeHGlobal(IntPtr)*
>> *      1.91 % {ctor} - 1279 ms - 1443841 calls -
>> .{ctor}(basic_string<char, std::char_traits<char>, std::allocator<char> > *,
>> SByte *)   (from
>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>> *      1.84 % {ctor} - 1232 ms - 1443840 calls -
>> .{ctor}(basic_string<char, std::char_traits<char>, std::allocator<char> > *,
>> basic_string<char, std::char_traits<char>, std::allocator<char> > *)   (from
>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>> *      1.77 % {dtor}* - 1186 ms - 1443840 calls -
>> .{dtor}*(basic_string<char, std::char_traits<char>, std::allocator<char> >
>> *)   (from std.basic_string<char,std::char_traits<char>,std::allocator<char>
>> >)*
>> *    28.02 % setField - 18736 ms - 1443840 calls - .setField(FieldMap *,
>> FieldBase *, Boolean)   (from FIX.FieldMap)*
>> *      16.82 % find - 11248 ms - 1443840 calls -
>> .find(_Tree<std::_Tmap_traits<int, FIX::FieldBase, FIX::message_order,
>> std::allocator<std::pair<int const, FIX::FieldBase> >, 1> > *, iterator *,
>> Int32 *)   (from
>> std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,std::allocator<std::pair<int
>> const ,FIX::FieldBase> >,1> >)*
>> *        11.85 % _Lbound - 7925 ms - 1443840 calls -
>> ._Lbound(_Tree<std::_Tmap_traits<int, FIX::FieldBase, FIX::message_order,
>> std::allocator<std::pair<int const, FIX::FieldBase> >, 1> > *, Int32 *)
>> (from
>> std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,std::allocator<std::pair<int
>> const ,FIX::FieldBase> >,1> >)*
>> *          5.76 % () - 3853 ms - 5775360 calls - .()(message_order *,
>> Int32 *, Int32 *)   (from FIX.message_order)*
>> *        1.40 % () - 936 ms - 1443840 calls - .()(message_order *, Int32
>> *, Int32 *)   (from FIX.message_order)*
>> *      7.47 % = - 4992 ms - 1443840 calls - .=(FieldBase *, FieldBase *)
>>   (from FIX.FieldBase)*
>> *        2.87 % =* - 1919 ms - 2887680 calls - .=*(basic_string<char,
>> std::char_traits<char>, std::allocator<char> > *, basic_string<char,
>> std::char_traits<char>, std::allocator<char> > *)   (from
>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>> *    4.57 % {dtor}* - 3058 ms - 4331520 calls -
>> .{dtor}*(basic_string<char, std::char_traits<char>, std::allocator<char> >
>> *)   (from std.basic_string<char,std::char_traits<char>,std::allocator<char>
>> >)*
>> *    1.61 % {ctor} - 1076 ms - 1443840 calls - .{ctor}(basic_string<char,
>> std::char_traits<char>, std::allocator<char> > *)   (from
>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>> *    1.49 % {ctor} - 998 ms - 1443840 calls - .{ctor}(basic_string<char,
>> std::char_traits<char>, std::allocator<char> > *, basic_string<char,
>> std::char_traits<char>, std::allocator<char> > *)   (from
>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>>
>>
>> *Downward trace*
>> *100.00 % **setField** - 18439 ms - 393141 calls -
>> QuickFix.Message.setField(Int32, String)*
>> *  97.29 % mapSetField - 17940 ms - 393141 calls - .mapSetField(Int32,
>> String, FieldMap *)   (from QuickFix)*
>> *    50.25 % convertString - 9266 ms - 393141 calls -
>> .convertString(basic_string<char, std::char_traits<char>,
>> std::allocator<char> > *, String)   (from QuickFix)*
>> *      18.36 % Compare - 3385 ms - 393141 calls -
>> System.String.Compare(String, String)*
>> *      10.74 % createUnmanagedString - 1981 ms - 393141 calls -
>> .createUnmanagedString(String)   (from QuickFix)*
>> *        7.61 % StringToHGlobalAnsi - 1404 ms - 393141 calls -
>> System.Runtime.InteropServices.Marshal.StringToHGlobalAnsi(String)*
>> *      7.70 % FreeHGlobal - 1420 ms - 393141 calls -
>> System.Runtime.InteropServices.Marshal.FreeHGlobal(IntPtr)*
>> *      1.78 % {ctor} - 328 ms - 393141 calls - .{ctor}(basic_string<char,
>> std::char_traits<char>, std::allocator<char> > *, basic_string<char,
>> std::char_traits<char>, std::allocator<char> > *)   (from
>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>> *      1.69 % {ctor} - 312 ms - 393141 calls - .{ctor}(basic_string<char,
>> std::char_traits<char>, std::allocator<char> > *, SByte *)   (from
>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>> *      0.93 % {dtor}* - 172 ms - 393141 calls -
>> .{dtor}*(basic_string<char, std::char_traits<char>, std::allocator<char> >
>> *)   (from std.basic_string<char,std::char_traits<char>,std::allocator<char>
>> >)*
>> *    40.69 % setField - 7504 ms - 393141 calls - .setField(FieldMap *,
>> Int32, basic_string<char, std::char_traits<char>, std::allocator<char> > *)
>>   (from FIX.FieldMap)*
>> *      25.63 % setField - 4727 ms - 393141 calls - .setField(FieldMap *,
>> FieldBase *, Boolean)   (from FIX.FieldMap)*
>> *        14.97 % find - 2761 ms - 393141 calls -
>> .find(_Tree<std::_Tmap_traits<int, FIX::FieldBase, FIX::message_order,
>> std::allocator<std::pair<int const, FIX::FieldBase> >, 1> > *, iterator *,
>> Int32 *)   (from
>> std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,std::allocator<std::pair<int
>> const ,FIX::FieldBase> >,1> >)*
>> *          10.49 % _Lbound - 1934 ms - 393141 calls -
>> ._Lbound(_Tree<std::_Tmap_traits<int, FIX::FieldBase, FIX::message_order,
>> std::allocator<std::pair<int const, FIX::FieldBase> >, 1> > *, Int32 *)
>> (from
>> std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,std::allocator<std::pair<int
>> const ,FIX::FieldBase> >,1> >)*
>> *          1.02 % () - 187 ms - 393141 calls - .()(message_order *, Int32
>> *, Int32 *)   (from FIX.message_order)*
>> *        7.02 % = - 1295 ms - 393141 calls - .=(FieldBase *, FieldBase *)
>>   (from FIX.FieldBase)*
>> *          2.45 % =* - 452 ms - 786282 calls - .=*(basic_string<char,
>> std::char_traits<char>, std::allocator<char> > *, basic_string<char,
>> std::char_traits<char>, std::allocator<char> > *)   (from
>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>> *      3.05 % {dtor}* - 562 ms - 786282 calls -
>> .{dtor}*(basic_string<char, std::char_traits<char>, std::allocator<char> >
>> *)   (from std.basic_string<char,std::char_traits<char>,std::allocator<char>
>> >)*
>> *      1.61 % {ctor} - 296 ms - 393141 calls - .{ctor}(basic_string<char,
>> std::char_traits<char>, std::allocator<char> > *, basic_string<char,
>> std::char_traits<char>, std::allocator<char> > *)   (from
>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>> *      1.61 % {ctor} - 296 ms - 393141 calls - .{ctor}(basic_string<char,
>> std::char_traits<char>, std::allocator<char> > *)   (from
>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>> *    0.76 % {dtor}* - 140 ms - 393141 calls - .{dtor}*(basic_string<char,
>> std::char_traits<char>, std::allocator<char> > *)   (from
>> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>>
>>
>> The destructor also, may be there is a way to use a pool of messages
>> instead of really disposing them?
>> *
>> *
>> *Upward trace*
>> *6.89 % {**dtor**}* - 19266 ms - 796435 calls - .{dtor}*(FieldMap *)
>> (from FIX.FieldMap)*
>> *  4.64 % __vecDelDtor - 12979 of 19266 ms - 443321 of 796435 calls -
>> .__vecDelDtor(FieldMap *, UInt32)   (from FIX.FieldMap)*
>> *    2.61 % {dtor}* - 7301 of 19266 ms - 221660 of 796435 calls -
>> .{dtor}*(FieldMap *)   (from FIX.FieldMap)*
>> *      2.61 % {dtor} - 7301 of 19266 ms - 221660 of 796435 calls -
>> .{dtor}(Message *)   (from FIX.Message)*
>> *        2.61 % __vecDelDtor - 7301 of 19266 ms - 221660 of 796435 calls
>> - .__vecDelDtor(Message *, UInt32)   (from FIX.Message)*
>> *          2.61 % ?function?* - 7301 of 19266 ms - 221660 of 796435 calls
>> - ?class?.?function?*(?parameters?)*
>> *            2.61 % **Dispose **- 7301 of 19266 ms - 221660 of 796435
>> calls - QuickFix.Message.Dispose()*
>> *              1.70 % Finalize - 4742 of 19266 ms - 111139 of 796435
>> calls - QuickFix.Message.Finalize()*
>> *              0.91 % fromApp - 2558 of 19266 ms - 110457 of 796435 calls
>> - POLR.Gateway.Application_Initiator.fromApp(Message, SessionID)*
>> *              0.00 % DisconnectInstrumentIfNeeded - 0 of 19266 ms - 16
>> of 796435 calls - POLR.Gateway.PG_Util.DisconnectInstrumentIfNeeded(Message,
>> InstrumentID)*
>> *              0.00 % AcceptorFromApp_InitiatorToApp - 0 of 19266 ms - 48
>> of 796435 calls -
>> POLR.Gateway.Application_Acceptor.AcceptorFromApp_InitiatorToApp(Message,
>> SessionID)*
>> *    0.96 % =* - 2699 of 19266 ms - 111140 of 796435 calls - .=*(FieldMap
>> *, FieldMap *)   (from FIX.FieldMap)*
>> *    0.76 % Thread #6673184 - 2137 of 19266 ms - 76059 of 796435 calls*
>> *    0.09 % Thread #6646824 - 250 of 19266 ms - 13712 of 796435 calls*
>> *    0.00 % Thread #6648528 - 0 of 19266 ms - 24 of 796435 calls*
>> *  1.40 % {dtor} - 3916 of 19266 ms - 242571 of 796435 calls -
>> .{dtor}(Message *)   (from FIX.Message)*
>> *  0.85 % {dtor} - 2371 of 19266 ms - 110543 of 796435 calls -
>> .{dtor}(Group *)   (from FIX.Group)*
>>
>>
>> (please do not compare the timeframe in those 2 subtrees, just look at
>> what functions cost a lot)
>> Something to note from other tests setString is faster than setField but
>> getField is way faster than getString
>> I there faster other functions that I could use? thanks
>>
>>
>> Here is another one very expensive
>> *UpwardTrace*
>> *37.22 % **=*** - 104131 ms - 364156 calls - .=*(FieldMap *, FieldMap *)
>>   (from FIX.FieldMap)*
>> *  37.22 % = - 104131 of 104131 ms - 364134 of 364156 calls - .=(Message
>> *, Message *)   (from FIX.Message)*
>> *    25.48 % **setUnmanaged **- 71277 of 104131 ms - 242568 of 364156
>> calls - QuickFix.Message.setUnmanaged(Message *)*
>> *      25.48 % create - 71277 of 104131 ms - 242568 of 364156 calls -
>> .create(Application *, Message *)   (from Application)*
>> *        12.85 % toApp - 35958 of 104131 ms - 118278 of 364156 calls -
>> .toApp(Application *, Message *, SessionID *)   (from Application)*
>> *          12.85 % sendToTarget* - 35958 of 104131 ms - 118278 of 364156
>> calls - .sendToTarget*(Message *, SenderCompID *, TargetCompID *,
>> basic_string<char, std::char_traits<char>, std::allocator<char> > *)   (from
>> FIX.Session)*
>> *            12.85 % sendToTarget - 35958 of 104131 ms - 118278 of 364156
>> calls - QuickFix.Session.sendToTarget(Message, String, String)*
>> *              12.83 % InitiatorFromApp_AcceptorToApp - 35896 of 104131
>> ms - 117762 of 364156 calls -
>> POLR.Gateway.Application_Initiator.InitiatorFromApp_AcceptorToApp(Message,
>> SessionID)*
>> *              0.02 % onLogon - 47 of 104131 ms - 480 of 364156 calls -
>> POLR.Gateway.Application_Initiator.onLogon(SessionID)*
>> *              0.01 % AcceptorFromApp_InitiatorToApp - 16 of 104131 ms -
>> 27 of 364156 calls -
>> POLR.Gateway.Application_Acceptor.AcceptorFromApp_InitiatorToApp(Message,
>> SessionID)*
>> *              0.00 % ReconnectToInstrumentsFeed - 0 of 104131 ms - 3 of
>> 364156 calls - POLR.Gateway.PG_Util.ReconnectToInstrumentsFeed()*
>> *              0.00 % DisconnectInstrumentIfNeeded - 0 of 104131 ms - 6
>> of 364156 calls - POLR.Gateway.PG_Util.DisconnectInstrumentIfNeeded(Message,
>> InstrumentID)*
>> *        12.59 % fromApp - 35209 of 104131 ms - 117813 of 364156 calls -
>> .fromApp(Application *, Message *, SessionID *)   (from Application)*
>> *        0.02 % toAdmin - 62 of 104131 ms - 3288 of 364156 calls -
>> .toAdmin(Application *, Message *, SessionID *)   (from Application)*
>> *        0.02 % fromAdmin - 47 of 104131 ms - 3189 of 364156 calls -
>> .fromAdmin(Application *, Message *, SessionID *)   (from Application)*
>> *    11.73 % toApp - 32823 of 104131 ms - 118278 of 364156 calls -
>> .toApp(Application *, Message *, SessionID *)   (from Application)*
>> *    0.01 % toAdmin - 31 of 104131 ms - 3288 of 364156 calls -
>> .toAdmin(Application *, Message *, SessionID *)   (from Application)*
>> *  0.00 % getGroup - 0 of 104131 ms - 22 of 364156 calls -
>> .getGroup(FieldMap *, Int32, Int32, FieldMap *)   (from FIX.FieldMap)*
>>
>> Here is a set from a long test of the function that take most of the time
>>
>>    1. *FieldMap * .=*(FieldMap *, FieldMap *)   (from FIX.FieldMap)*
>>    2. *message_order * .=*(message_order *, message_order *)   (from
>>    FIX.message_order)*
>>    3. *Void .delete[]*(Void *)*
>>    4. *Void ._Adopt(_Iterator_base *, _Container_base_secure *)   (from
>>    std._Iterator_base)*
>>    5. *Void .{dtor}*(FieldMap *)   (from FIX.FieldMap)*
>>    6. *Message .create(Application *, Message *)   (from Application)*
>>    7. *Group QuickFix.Message.getGroup(UInt32, Group)*
>>    8. *String QuickFix.Group.getField(Int32)*
>>    9. *MDEntrySize
>>    QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDEntrySize()*
>>    10. *MDEntryPx
>>    QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDEntryPx()*
>>    11. *MDEntryType
>>    QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDEntryType()*
>>    12. *NoMDEntries
>>    QuickFix42.MarketDataIncrementalRefresh.getNoMDEntries()*
>>    13. *MDEntryPositionNo
>>    QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDEntryPositionNo()
>>    *
>>    14. *MDUpdateAction
>>    QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDUpdateAction()
>>    *
>>    15. *Void QuickFix42.MarketDataIncrementalRefresh.NoMDEntries..ctor()*
>>    16. *UtcTimeStamp * .getCreationTime(MessageStore *, UtcTimeStamp *)
>>    (from MessageStore)*
>>    17. *MDReqID QuickFix42.MarketDataIncrementalRefresh.getMDReqID()*
>>    18. *Boolean
>>    QuickFix42.MarketDataIncrementalRefresh.isSetNoMDEntries()*
>>    19. *Void System.Windows.Forms.TextBoxBase.AppendText(String)*
>>    20. *Object System.Delegate.DynamicInvokeImpl(Object [])*
>>
>>
>>
>> Something else:
>> Is there a way to totally disable the Dictionary check even with repeating
>> group, like I have 2 machines that I control, I already run them with the
>> dictionary enable and everything is fine, now I want to run them without the
>> dictionary check as I know those machines won't change.....
>>
>> Thanks
>>
>> Wil
>>
>> On Wed, Jun 23, 2010 at 5:48 PM, Hei Chan <str...@ya...>wrote:
>>
>>> QuickFIX Documentation:
>>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>>
>>> Hi,
>>>
>>> I just wonder whether anyone has compared the performance of the latest
>>> quickfix/C++ 1.13.3 with 1.12.4.
>>>
>>> With 1.12.4 (with a small modification -- added support to set send
>>> buffer size), it seems to be faster than 1.13.3 during my ping test:
>>> - A server logs the timestamp and sends me a "ping" FIX message.
>>> - My server replies and the server logs the timestamp when it receives my
>>> reply.
>>>
>>> The ping time increased from 2.2275ms to 2.65833ms out of 120 pings
>>> within an hour.
>>>
>>> Although I understand that it is not a very accurate measure (since the
>>> time isn't logged in microsecond and # of samples are few), it roughly
>>> indicates some performance degradation.
>>>
>>> I am not saying that there must be a performance degradation...
>>>
>>> But I am curious whether anyone on the list can share some stats...
>>>
>>> Thanks in advance.
>>>
>>>
>>> Cheers,
>>> Hei
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>> _______________________________________________
>>> Quickfix-users mailing list
>>> Qui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>
>

Re: [Quickfix-developers] [Quickfix-users] Performance

[Kenny S. <ks...@co...>]

There are a number of validation tunings you can set in the config file that
will have some impact on performance (less validation == faster)

http://quickfixengine.org/quickfix/doc/html/configuration.html

Data dictionary is required for parsing repeating groups.

--
Kenny Stone
Connamara Systems, LLC


On Wed, Sep 22, 2010 at 12:54 PM, Wilhelm Thomas <th...@cu...>wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> Hello
>
> On the performance side here are some numbers, not really comparing 2
> version but just showing where the time is spent....
>
> setString, setField and their get counter part seem pretty slow:
>
> *Downward trace*
> *100.00 % setString - 66862* ms - 1443841 calls -
> QuickFix.Message.setString(Int32, String)*
> *  97.76 % mapSetString - 65364* ms - 1443841 calls - .mapSetString(Int32,
> String, FieldMap *)   (from QuickFix)*
> *    50.51 % convertString - 33774* ms - 1443841 calls -
> .convertString(basic_string<char, std::char_traits<char>,
> std::allocator<char> > *, String)   (from QuickFix)*
> *      16.75 %** Compare - 11201 ms **- 1443841 calls -
> System.String.Compare(String, String)*
> *      12.81 % createUnmanagedString - 8564 ms - 1443841 calls -
> .createUnmanagedString(String)   (from QuickFix)*
> *        10.10 %** StringToHGlobalAnsi - 6755 ms -** 1443841 calls -
> System.Runtime.InteropServices.Marshal.StringToHGlobalAnsi(String)*
> *      6.16 % FreeHGlobal - 4118 ms - 1443841 calls -
> System.Runtime.InteropServices.Marshal.FreeHGlobal(IntPtr)*
> *      1.91 % {ctor} - 1279 ms - 1443841 calls -
> .{ctor}(basic_string<char, std::char_traits<char>, std::allocator<char> > *,
> SByte *)   (from
> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
> *      1.84 % {ctor} - 1232 ms - 1443840 calls -
> .{ctor}(basic_string<char, std::char_traits<char>, std::allocator<char> > *,
> basic_string<char, std::char_traits<char>, std::allocator<char> > *)   (from
> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
> *      1.77 % {dtor}* - 1186 ms - 1443840 calls -
> .{dtor}*(basic_string<char, std::char_traits<char>, std::allocator<char> >
> *)   (from std.basic_string<char,std::char_traits<char>,std::allocator<char>
> >)*
> *    28.02 % setField - 18736 ms - 1443840 calls - .setField(FieldMap *,
> FieldBase *, Boolean)   (from FIX.FieldMap)*
> *      16.82 % find - 11248 ms - 1443840 calls -
> .find(_Tree<std::_Tmap_traits<int, FIX::FieldBase, FIX::message_order,
> std::allocator<std::pair<int const, FIX::FieldBase> >, 1> > *, iterator *,
> Int32 *)   (from
> std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,std::allocator<std::pair<int
> const ,FIX::FieldBase> >,1> >)*
> *        11.85 % _Lbound - 7925 ms - 1443840 calls -
> ._Lbound(_Tree<std::_Tmap_traits<int, FIX::FieldBase, FIX::message_order,
> std::allocator<std::pair<int const, FIX::FieldBase> >, 1> > *, Int32 *)
> (from
> std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,std::allocator<std::pair<int
> const ,FIX::FieldBase> >,1> >)*
> *          5.76 % () - 3853 ms - 5775360 calls - .()(message_order *,
> Int32 *, Int32 *)   (from FIX.message_order)*
> *        1.40 % () - 936 ms - 1443840 calls - .()(message_order *, Int32
> *, Int32 *)   (from FIX.message_order)*
> *      7.47 % = - 4992 ms - 1443840 calls - .=(FieldBase *, FieldBase *)
> (from FIX.FieldBase)*
> *        2.87 % =* - 1919 ms - 2887680 calls - .=*(basic_string<char,
> std::char_traits<char>, std::allocator<char> > *, basic_string<char,
> std::char_traits<char>, std::allocator<char> > *)   (from
> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
> *    4.57 % {dtor}* - 3058 ms - 4331520 calls -
> .{dtor}*(basic_string<char, std::char_traits<char>, std::allocator<char> >
> *)   (from std.basic_string<char,std::char_traits<char>,std::allocator<char>
> >)*
> *    1.61 % {ctor} - 1076 ms - 1443840 calls - .{ctor}(basic_string<char,
> std::char_traits<char>, std::allocator<char> > *)   (from
> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
> *    1.49 % {ctor} - 998 ms - 1443840 calls - .{ctor}(basic_string<char,
> std::char_traits<char>, std::allocator<char> > *, basic_string<char,
> std::char_traits<char>, std::allocator<char> > *)   (from
> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>
>
> *Downward trace*
> *100.00 % **setField** - 18439 ms - 393141 calls -
> QuickFix.Message.setField(Int32, String)*
> *  97.29 % mapSetField - 17940 ms - 393141 calls - .mapSetField(Int32,
> String, FieldMap *)   (from QuickFix)*
> *    50.25 % convertString - 9266 ms - 393141 calls -
> .convertString(basic_string<char, std::char_traits<char>,
> std::allocator<char> > *, String)   (from QuickFix)*
> *      18.36 % Compare - 3385 ms - 393141 calls -
> System.String.Compare(String, String)*
> *      10.74 % createUnmanagedString - 1981 ms - 393141 calls -
> .createUnmanagedString(String)   (from QuickFix)*
> *        7.61 % StringToHGlobalAnsi - 1404 ms - 393141 calls -
> System.Runtime.InteropServices.Marshal.StringToHGlobalAnsi(String)*
> *      7.70 % FreeHGlobal - 1420 ms - 393141 calls -
> System.Runtime.InteropServices.Marshal.FreeHGlobal(IntPtr)*
> *      1.78 % {ctor} - 328 ms - 393141 calls - .{ctor}(basic_string<char,
> std::char_traits<char>, std::allocator<char> > *, basic_string<char,
> std::char_traits<char>, std::allocator<char> > *)   (from
> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
> *      1.69 % {ctor} - 312 ms - 393141 calls - .{ctor}(basic_string<char,
> std::char_traits<char>, std::allocator<char> > *, SByte *)   (from
> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
> *      0.93 % {dtor}* - 172 ms - 393141 calls -
> .{dtor}*(basic_string<char, std::char_traits<char>, std::allocator<char> >
> *)   (from std.basic_string<char,std::char_traits<char>,std::allocator<char>
> >)*
> *    40.69 % setField - 7504 ms - 393141 calls - .setField(FieldMap *,
> Int32, basic_string<char, std::char_traits<char>, std::allocator<char> > *)
>   (from FIX.FieldMap)*
> *      25.63 % setField - 4727 ms - 393141 calls - .setField(FieldMap *,
> FieldBase *, Boolean)   (from FIX.FieldMap)*
> *        14.97 % find - 2761 ms - 393141 calls -
> .find(_Tree<std::_Tmap_traits<int, FIX::FieldBase, FIX::message_order,
> std::allocator<std::pair<int const, FIX::FieldBase> >, 1> > *, iterator *,
> Int32 *)   (from
> std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,std::allocator<std::pair<int
> const ,FIX::FieldBase> >,1> >)*
> *          10.49 % _Lbound - 1934 ms - 393141 calls -
> ._Lbound(_Tree<std::_Tmap_traits<int, FIX::FieldBase, FIX::message_order,
> std::allocator<std::pair<int const, FIX::FieldBase> >, 1> > *, Int32 *)
> (from
> std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,std::allocator<std::pair<int
> const ,FIX::FieldBase> >,1> >)*
> *          1.02 % () - 187 ms - 393141 calls - .()(message_order *, Int32
> *, Int32 *)   (from FIX.message_order)*
> *        7.02 % = - 1295 ms - 393141 calls - .=(FieldBase *, FieldBase *)
>   (from FIX.FieldBase)*
> *          2.45 % =* - 452 ms - 786282 calls - .=*(basic_string<char,
> std::char_traits<char>, std::allocator<char> > *, basic_string<char,
> std::char_traits<char>, std::allocator<char> > *)   (from
> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
> *      3.05 % {dtor}* - 562 ms - 786282 calls -
> .{dtor}*(basic_string<char, std::char_traits<char>, std::allocator<char> >
> *)   (from std.basic_string<char,std::char_traits<char>,std::allocator<char>
> >)*
> *      1.61 % {ctor} - 296 ms - 393141 calls - .{ctor}(basic_string<char,
> std::char_traits<char>, std::allocator<char> > *, basic_string<char,
> std::char_traits<char>, std::allocator<char> > *)   (from
> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
> *      1.61 % {ctor} - 296 ms - 393141 calls - .{ctor}(basic_string<char,
> std::char_traits<char>, std::allocator<char> > *)   (from
> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
> *    0.76 % {dtor}* - 140 ms - 393141 calls - .{dtor}*(basic_string<char,
> std::char_traits<char>, std::allocator<char> > *)   (from
> std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
>
>
> The destructor also, may be there is a way to use a pool of messages
> instead of really disposing them?
> *
> *
> *Upward trace*
> *6.89 % {**dtor**}* - 19266 ms - 796435 calls - .{dtor}*(FieldMap *)
> (from FIX.FieldMap)*
> *  4.64 % __vecDelDtor - 12979 of 19266 ms - 443321 of 796435 calls -
> .__vecDelDtor(FieldMap *, UInt32)   (from FIX.FieldMap)*
> *    2.61 % {dtor}* - 7301 of 19266 ms - 221660 of 796435 calls -
> .{dtor}*(FieldMap *)   (from FIX.FieldMap)*
> *      2.61 % {dtor} - 7301 of 19266 ms - 221660 of 796435 calls -
> .{dtor}(Message *)   (from FIX.Message)*
> *        2.61 % __vecDelDtor - 7301 of 19266 ms - 221660 of 796435 calls -
> .__vecDelDtor(Message *, UInt32)   (from FIX.Message)*
> *          2.61 % ?function?* - 7301 of 19266 ms - 221660 of 796435 calls
> - ?class?.?function?*(?parameters?)*
> *            2.61 % **Dispose **- 7301 of 19266 ms - 221660 of 796435
> calls - QuickFix.Message.Dispose()*
> *              1.70 % Finalize - 4742 of 19266 ms - 111139 of 796435 calls
> - QuickFix.Message.Finalize()*
> *              0.91 % fromApp - 2558 of 19266 ms - 110457 of 796435 calls
> - POLR.Gateway.Application_Initiator.fromApp(Message, SessionID)*
> *              0.00 % DisconnectInstrumentIfNeeded - 0 of 19266 ms - 16 of
> 796435 calls - POLR.Gateway.PG_Util.DisconnectInstrumentIfNeeded(Message,
> InstrumentID)*
> *              0.00 % AcceptorFromApp_InitiatorToApp - 0 of 19266 ms - 48
> of 796435 calls -
> POLR.Gateway.Application_Acceptor.AcceptorFromApp_InitiatorToApp(Message,
> SessionID)*
> *    0.96 % =* - 2699 of 19266 ms - 111140 of 796435 calls - .=*(FieldMap
> *, FieldMap *)   (from FIX.FieldMap)*
> *    0.76 % Thread #6673184 - 2137 of 19266 ms - 76059 of 796435 calls*
> *    0.09 % Thread #6646824 - 250 of 19266 ms - 13712 of 796435 calls*
> *    0.00 % Thread #6648528 - 0 of 19266 ms - 24 of 796435 calls*
> *  1.40 % {dtor} - 3916 of 19266 ms - 242571 of 796435 calls -
> .{dtor}(Message *)   (from FIX.Message)*
> *  0.85 % {dtor} - 2371 of 19266 ms - 110543 of 796435 calls -
> .{dtor}(Group *)   (from FIX.Group)*
>
>
> (please do not compare the timeframe in those 2 subtrees, just look at what
> functions cost a lot)
> Something to note from other tests setString is faster than setField but
> getField is way faster than getString
> I there faster other functions that I could use? thanks
>
>
> Here is another one very expensive
> *UpwardTrace*
> *37.22 % **=*** - 104131 ms - 364156 calls - .=*(FieldMap *, FieldMap *)
> (from FIX.FieldMap)*
> *  37.22 % = - 104131 of 104131 ms - 364134 of 364156 calls - .=(Message
> *, Message *)   (from FIX.Message)*
> *    25.48 % **setUnmanaged **- 71277 of 104131 ms - 242568 of 364156
> calls - QuickFix.Message.setUnmanaged(Message *)*
> *      25.48 % create - 71277 of 104131 ms - 242568 of 364156 calls -
> .create(Application *, Message *)   (from Application)*
> *        12.85 % toApp - 35958 of 104131 ms - 118278 of 364156 calls -
> .toApp(Application *, Message *, SessionID *)   (from Application)*
> *          12.85 % sendToTarget* - 35958 of 104131 ms - 118278 of 364156
> calls - .sendToTarget*(Message *, SenderCompID *, TargetCompID *,
> basic_string<char, std::char_traits<char>, std::allocator<char> > *)   (from
> FIX.Session)*
> *            12.85 % sendToTarget - 35958 of 104131 ms - 118278 of 364156
> calls - QuickFix.Session.sendToTarget(Message, String, String)*
> *              12.83 % InitiatorFromApp_AcceptorToApp - 35896 of 104131 ms
> - 117762 of 364156 calls -
> POLR.Gateway.Application_Initiator.InitiatorFromApp_AcceptorToApp(Message,
> SessionID)*
> *              0.02 % onLogon - 47 of 104131 ms - 480 of 364156 calls -
> POLR.Gateway.Application_Initiator.onLogon(SessionID)*
> *              0.01 % AcceptorFromApp_InitiatorToApp - 16 of 104131 ms -
> 27 of 364156 calls -
> POLR.Gateway.Application_Acceptor.AcceptorFromApp_InitiatorToApp(Message,
> SessionID)*
> *              0.00 % ReconnectToInstrumentsFeed - 0 of 104131 ms - 3 of
> 364156 calls - POLR.Gateway.PG_Util.ReconnectToInstrumentsFeed()*
> *              0.00 % DisconnectInstrumentIfNeeded - 0 of 104131 ms - 6 of
> 364156 calls - POLR.Gateway.PG_Util.DisconnectInstrumentIfNeeded(Message,
> InstrumentID)*
> *        12.59 % fromApp - 35209 of 104131 ms - 117813 of 364156 calls -
> .fromApp(Application *, Message *, SessionID *)   (from Application)*
> *        0.02 % toAdmin - 62 of 104131 ms - 3288 of 364156 calls -
> .toAdmin(Application *, Message *, SessionID *)   (from Application)*
> *        0.02 % fromAdmin - 47 of 104131 ms - 3189 of 364156 calls -
> .fromAdmin(Application *, Message *, SessionID *)   (from Application)*
> *    11.73 % toApp - 32823 of 104131 ms - 118278 of 364156 calls -
> .toApp(Application *, Message *, SessionID *)   (from Application)*
> *    0.01 % toAdmin - 31 of 104131 ms - 3288 of 364156 calls -
> .toAdmin(Application *, Message *, SessionID *)   (from Application)*
> *  0.00 % getGroup - 0 of 104131 ms - 22 of 364156 calls -
> .getGroup(FieldMap *, Int32, Int32, FieldMap *)   (from FIX.FieldMap)*
>
> Here is a set from a long test of the function that take most of the time
>
>    1. *FieldMap * .=*(FieldMap *, FieldMap *)   (from FIX.FieldMap)*
>    2. *message_order * .=*(message_order *, message_order *)   (from
>    FIX.message_order)*
>    3. *Void .delete[]*(Void *)*
>    4. *Void ._Adopt(_Iterator_base *, _Container_base_secure *)   (from
>    std._Iterator_base)*
>    5. *Void .{dtor}*(FieldMap *)   (from FIX.FieldMap)*
>    6. *Message .create(Application *, Message *)   (from Application)*
>    7. *Group QuickFix.Message.getGroup(UInt32, Group)*
>    8. *String QuickFix.Group.getField(Int32)*
>    9. *MDEntrySize
>    QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDEntrySize()*
>    10. *MDEntryPx
>    QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDEntryPx()*
>    11. *MDEntryType
>    QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDEntryType()*
>    12. *NoMDEntries
>    QuickFix42.MarketDataIncrementalRefresh.getNoMDEntries()*
>    13. *MDEntryPositionNo
>    QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDEntryPositionNo()
>    *
>    14. *MDUpdateAction
>    QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDUpdateAction()
>    *
>    15. *Void QuickFix42.MarketDataIncrementalRefresh.NoMDEntries..ctor()*
>    16. *UtcTimeStamp * .getCreationTime(MessageStore *, UtcTimeStamp *)
>    (from MessageStore)*
>    17. *MDReqID QuickFix42.MarketDataIncrementalRefresh.getMDReqID()*
>    18. *Boolean QuickFix42.MarketDataIncrementalRefresh.isSetNoMDEntries()
>    *
>    19. *Void System.Windows.Forms.TextBoxBase.AppendText(String)*
>    20. *Object System.Delegate.DynamicInvokeImpl(Object [])*
>
>
>
> Something else:
> Is there a way to totally disable the Dictionary check even with repeating
> group, like I have 2 machines that I control, I already run them with the
> dictionary enable and everything is fine, now I want to run them without the
> dictionary check as I know those machines won't change.....
>
> Thanks
>
> Wil
>
> On Wed, Jun 23, 2010 at 5:48 PM, Hei Chan <str...@ya...>wrote:
>
>> QuickFIX Documentation:
>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> Hi,
>>
>> I just wonder whether anyone has compared the performance of the latest
>> quickfix/C++ 1.13.3 with 1.12.4.
>>
>> With 1.12.4 (with a small modification -- added support to set send buffer
>> size), it seems to be faster than 1.13.3 during my ping test:
>> - A server logs the timestamp and sends me a "ping" FIX message.
>> - My server replies and the server logs the timestamp when it receives my
>> reply.
>>
>> The ping time increased from 2.2275ms to 2.65833ms out of 120 pings within
>> an hour.
>>
>> Although I understand that it is not a very accurate measure (since the
>> time isn't logged in microsecond and # of samples are few), it roughly
>> indicates some performance degradation.
>>
>> I am not saying that there must be a performance degradation...
>>
>> But I am curious whether anyone on the list can share some stats...
>>
>> Thanks in advance.
>>
>>
>> Cheers,
>> Hei
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Quickfix-users mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>>
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] [Quickfix-users] Performance

[Wilhelm T. <th...@cu...>]

Hello

On the performance side here are some numbers, not really comparing 2
version but just showing where the time is spent....

setString, setField and their get counter part seem pretty slow:

*Downward trace*
*100.00 % setString - 66862* ms - 1443841 calls -
QuickFix.Message.setString(Int32, String)*
*  97.76 % mapSetString - 65364* ms - 1443841 calls - .mapSetString(Int32,
String, FieldMap *)   (from QuickFix)*
*    50.51 % convertString - 33774* ms - 1443841 calls -
.convertString(basic_string<char, std::char_traits<char>,
std::allocator<char> > *, String)   (from QuickFix)*
*      16.75 %** Compare - 11201 ms **- 1443841 calls -
System.String.Compare(String, String)*
*      12.81 % createUnmanagedString - 8564 ms - 1443841 calls -
.createUnmanagedString(String)   (from QuickFix)*
*        10.10 %** StringToHGlobalAnsi - 6755 ms -** 1443841 calls -
System.Runtime.InteropServices.Marshal.StringToHGlobalAnsi(String)*
*      6.16 % FreeHGlobal - 4118 ms - 1443841 calls -
System.Runtime.InteropServices.Marshal.FreeHGlobal(IntPtr)*
*      1.91 % {ctor} - 1279 ms - 1443841 calls - .{ctor}(basic_string<char,
std::char_traits<char>, std::allocator<char> > *, SByte *)   (from
std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
*      1.84 % {ctor} - 1232 ms - 1443840 calls - .{ctor}(basic_string<char,
std::char_traits<char>, std::allocator<char> > *, basic_string<char,
std::char_traits<char>, std::allocator<char> > *)   (from
std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
*      1.77 % {dtor}* - 1186 ms - 1443840 calls -
.{dtor}*(basic_string<char, std::char_traits<char>, std::allocator<char> >
*)   (from std.basic_string<char,std::char_traits<char>,std::allocator<char>
>)*
*    28.02 % setField - 18736 ms - 1443840 calls - .setField(FieldMap *,
FieldBase *, Boolean)   (from FIX.FieldMap)*
*      16.82 % find - 11248 ms - 1443840 calls -
.find(_Tree<std::_Tmap_traits<int, FIX::FieldBase, FIX::message_order,
std::allocator<std::pair<int const, FIX::FieldBase> >, 1> > *, iterator *,
Int32 *)   (from
std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,std::allocator<std::pair<int
const ,FIX::FieldBase> >,1> >)*
*        11.85 % _Lbound - 7925 ms - 1443840 calls -
._Lbound(_Tree<std::_Tmap_traits<int, FIX::FieldBase, FIX::message_order,
std::allocator<std::pair<int const, FIX::FieldBase> >, 1> > *, Int32 *)
(from
std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,std::allocator<std::pair<int
const ,FIX::FieldBase> >,1> >)*
*          5.76 % () - 3853 ms - 5775360 calls - .()(message_order *, Int32
*, Int32 *)   (from FIX.message_order)*
*        1.40 % () - 936 ms - 1443840 calls - .()(message_order *, Int32 *,
Int32 *)   (from FIX.message_order)*
*      7.47 % = - 4992 ms - 1443840 calls - .=(FieldBase *, FieldBase *)
(from FIX.FieldBase)*
*        2.87 % =* - 1919 ms - 2887680 calls - .=*(basic_string<char,
std::char_traits<char>, std::allocator<char> > *, basic_string<char,
std::char_traits<char>, std::allocator<char> > *)   (from
std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
*    4.57 % {dtor}* - 3058 ms - 4331520 calls - .{dtor}*(basic_string<char,
std::char_traits<char>, std::allocator<char> > *)   (from
std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
*    1.61 % {ctor} - 1076 ms - 1443840 calls - .{ctor}(basic_string<char,
std::char_traits<char>, std::allocator<char> > *)   (from
std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
*    1.49 % {ctor} - 998 ms - 1443840 calls - .{ctor}(basic_string<char,
std::char_traits<char>, std::allocator<char> > *, basic_string<char,
std::char_traits<char>, std::allocator<char> > *)   (from
std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*


*Downward trace*
*100.00 % **setField** - 18439 ms - 393141 calls -
QuickFix.Message.setField(Int32, String)*
*  97.29 % mapSetField - 17940 ms - 393141 calls - .mapSetField(Int32,
String, FieldMap *)   (from QuickFix)*
*    50.25 % convertString - 9266 ms - 393141 calls -
.convertString(basic_string<char, std::char_traits<char>,
std::allocator<char> > *, String)   (from QuickFix)*
*      18.36 % Compare - 3385 ms - 393141 calls -
System.String.Compare(String, String)*
*      10.74 % createUnmanagedString - 1981 ms - 393141 calls -
.createUnmanagedString(String)   (from QuickFix)*
*        7.61 % StringToHGlobalAnsi - 1404 ms - 393141 calls -
System.Runtime.InteropServices.Marshal.StringToHGlobalAnsi(String)*
*      7.70 % FreeHGlobal - 1420 ms - 393141 calls -
System.Runtime.InteropServices.Marshal.FreeHGlobal(IntPtr)*
*      1.78 % {ctor} - 328 ms - 393141 calls - .{ctor}(basic_string<char,
std::char_traits<char>, std::allocator<char> > *, basic_string<char,
std::char_traits<char>, std::allocator<char> > *)   (from
std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
*      1.69 % {ctor} - 312 ms - 393141 calls - .{ctor}(basic_string<char,
std::char_traits<char>, std::allocator<char> > *, SByte *)   (from
std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
*      0.93 % {dtor}* - 172 ms - 393141 calls - .{dtor}*(basic_string<char,
std::char_traits<char>, std::allocator<char> > *)   (from
std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
*    40.69 % setField - 7504 ms - 393141 calls - .setField(FieldMap *,
Int32, basic_string<char, std::char_traits<char>, std::allocator<char> > *)
  (from FIX.FieldMap)*
*      25.63 % setField - 4727 ms - 393141 calls - .setField(FieldMap *,
FieldBase *, Boolean)   (from FIX.FieldMap)*
*        14.97 % find - 2761 ms - 393141 calls -
.find(_Tree<std::_Tmap_traits<int, FIX::FieldBase, FIX::message_order,
std::allocator<std::pair<int const, FIX::FieldBase> >, 1> > *, iterator *,
Int32 *)   (from
std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,std::allocator<std::pair<int
const ,FIX::FieldBase> >,1> >)*
*          10.49 % _Lbound - 1934 ms - 393141 calls -
._Lbound(_Tree<std::_Tmap_traits<int, FIX::FieldBase, FIX::message_order,
std::allocator<std::pair<int const, FIX::FieldBase> >, 1> > *, Int32 *)
(from
std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,std::allocator<std::pair<int
const ,FIX::FieldBase> >,1> >)*
*          1.02 % () - 187 ms - 393141 calls - .()(message_order *, Int32 *,
Int32 *)   (from FIX.message_order)*
*        7.02 % = - 1295 ms - 393141 calls - .=(FieldBase *, FieldBase *)
(from FIX.FieldBase)*
*          2.45 % =* - 452 ms - 786282 calls - .=*(basic_string<char,
std::char_traits<char>, std::allocator<char> > *, basic_string<char,
std::char_traits<char>, std::allocator<char> > *)   (from
std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
*      3.05 % {dtor}* - 562 ms - 786282 calls - .{dtor}*(basic_string<char,
std::char_traits<char>, std::allocator<char> > *)   (from
std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
*      1.61 % {ctor} - 296 ms - 393141 calls - .{ctor}(basic_string<char,
std::char_traits<char>, std::allocator<char> > *, basic_string<char,
std::char_traits<char>, std::allocator<char> > *)   (from
std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
*      1.61 % {ctor} - 296 ms - 393141 calls - .{ctor}(basic_string<char,
std::char_traits<char>, std::allocator<char> > *)   (from
std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*
*    0.76 % {dtor}* - 140 ms - 393141 calls - .{dtor}*(basic_string<char,
std::char_traits<char>, std::allocator<char> > *)   (from
std.basic_string<char,std::char_traits<char>,std::allocator<char> >)*


The destructor also, may be there is a way to use a pool of messages instead
of really disposing them?
*
*
*Upward trace*
*6.89 % {**dtor**}* - 19266 ms - 796435 calls - .{dtor}*(FieldMap *)   (from
FIX.FieldMap)*
*  4.64 % __vecDelDtor - 12979 of 19266 ms - 443321 of 796435 calls -
.__vecDelDtor(FieldMap *, UInt32)   (from FIX.FieldMap)*
*    2.61 % {dtor}* - 7301 of 19266 ms - 221660 of 796435 calls -
.{dtor}*(FieldMap *)   (from FIX.FieldMap)*
*      2.61 % {dtor} - 7301 of 19266 ms - 221660 of 796435 calls -
.{dtor}(Message *)   (from FIX.Message)*
*        2.61 % __vecDelDtor - 7301 of 19266 ms - 221660 of 796435 calls -
.__vecDelDtor(Message *, UInt32)   (from FIX.Message)*
*          2.61 % ?function?* - 7301 of 19266 ms - 221660 of 796435 calls -
?class?.?function?*(?parameters?)*
*            2.61 % **Dispose **- 7301 of 19266 ms - 221660 of 796435 calls
- QuickFix.Message.Dispose()*
*              1.70 % Finalize - 4742 of 19266 ms - 111139 of 796435 calls -
QuickFix.Message.Finalize()*
*              0.91 % fromApp - 2558 of 19266 ms - 110457 of 796435 calls -
POLR.Gateway.Application_Initiator.fromApp(Message, SessionID)*
*              0.00 % DisconnectInstrumentIfNeeded - 0 of 19266 ms - 16 of
796435 calls - POLR.Gateway.PG_Util.DisconnectInstrumentIfNeeded(Message,
InstrumentID)*
*              0.00 % AcceptorFromApp_InitiatorToApp - 0 of 19266 ms - 48 of
796435 calls -
POLR.Gateway.Application_Acceptor.AcceptorFromApp_InitiatorToApp(Message,
SessionID)*
*    0.96 % =* - 2699 of 19266 ms - 111140 of 796435 calls - .=*(FieldMap *,
FieldMap *)   (from FIX.FieldMap)*
*    0.76 % Thread #6673184 - 2137 of 19266 ms - 76059 of 796435 calls*
*    0.09 % Thread #6646824 - 250 of 19266 ms - 13712 of 796435 calls*
*    0.00 % Thread #6648528 - 0 of 19266 ms - 24 of 796435 calls*
*  1.40 % {dtor} - 3916 of 19266 ms - 242571 of 796435 calls -
.{dtor}(Message *)   (from FIX.Message)*
*  0.85 % {dtor} - 2371 of 19266 ms - 110543 of 796435 calls - .{dtor}(Group
*)   (from FIX.Group)*


(please do not compare the timeframe in those 2 subtrees, just look at what
functions cost a lot)
Something to note from other tests setString is faster than setField but
getField is way faster than getString
I there faster other functions that I could use? thanks


Here is another one very expensive
*UpwardTrace*
*37.22 % **=*** - 104131 ms - 364156 calls - .=*(FieldMap *, FieldMap *)
(from FIX.FieldMap)*
*  37.22 % = - 104131 of 104131 ms - 364134 of 364156 calls - .=(Message *,
Message *)   (from FIX.Message)*
*    25.48 % **setUnmanaged **- 71277 of 104131 ms - 242568 of 364156 calls
- QuickFix.Message.setUnmanaged(Message *)*
*      25.48 % create - 71277 of 104131 ms - 242568 of 364156 calls -
.create(Application *, Message *)   (from Application)*
*        12.85 % toApp - 35958 of 104131 ms - 118278 of 364156 calls -
.toApp(Application *, Message *, SessionID *)   (from Application)*
*          12.85 % sendToTarget* - 35958 of 104131 ms - 118278 of 364156
calls - .sendToTarget*(Message *, SenderCompID *, TargetCompID *,
basic_string<char, std::char_traits<char>, std::allocator<char> > *)   (from
FIX.Session)*
*            12.85 % sendToTarget - 35958 of 104131 ms - 118278 of 364156
calls - QuickFix.Session.sendToTarget(Message, String, String)*
*              12.83 % InitiatorFromApp_AcceptorToApp - 35896 of 104131 ms -
117762 of 364156 calls -
POLR.Gateway.Application_Initiator.InitiatorFromApp_AcceptorToApp(Message,
SessionID)*
*              0.02 % onLogon - 47 of 104131 ms - 480 of 364156 calls -
POLR.Gateway.Application_Initiator.onLogon(SessionID)*
*              0.01 % AcceptorFromApp_InitiatorToApp - 16 of 104131 ms - 27
of 364156 calls -
POLR.Gateway.Application_Acceptor.AcceptorFromApp_InitiatorToApp(Message,
SessionID)*
*              0.00 % ReconnectToInstrumentsFeed - 0 of 104131 ms - 3 of
364156 calls - POLR.Gateway.PG_Util.ReconnectToInstrumentsFeed()*
*              0.00 % DisconnectInstrumentIfNeeded - 0 of 104131 ms - 6 of
364156 calls - POLR.Gateway.PG_Util.DisconnectInstrumentIfNeeded(Message,
InstrumentID)*
*        12.59 % fromApp - 35209 of 104131 ms - 117813 of 364156 calls -
.fromApp(Application *, Message *, SessionID *)   (from Application)*
*        0.02 % toAdmin - 62 of 104131 ms - 3288 of 364156 calls -
.toAdmin(Application *, Message *, SessionID *)   (from Application)*
*        0.02 % fromAdmin - 47 of 104131 ms - 3189 of 364156 calls -
.fromAdmin(Application *, Message *, SessionID *)   (from Application)*
*    11.73 % toApp - 32823 of 104131 ms - 118278 of 364156 calls -
.toApp(Application *, Message *, SessionID *)   (from Application)*
*    0.01 % toAdmin - 31 of 104131 ms - 3288 of 364156 calls -
.toAdmin(Application *, Message *, SessionID *)   (from Application)*
*  0.00 % getGroup - 0 of 104131 ms - 22 of 364156 calls -
.getGroup(FieldMap *, Int32, Int32, FieldMap *)   (from FIX.FieldMap)*

Here is a set from a long test of the function that take most of the time

   1. *FieldMap * .=*(FieldMap *, FieldMap *)   (from FIX.FieldMap)*
   2. *message_order * .=*(message_order *, message_order *)   (from
   FIX.message_order)*
   3. *Void .delete[]*(Void *)*
   4. *Void ._Adopt(_Iterator_base *, _Container_base_secure *)   (from
   std._Iterator_base)*
   5. *Void .{dtor}*(FieldMap *)   (from FIX.FieldMap)*
   6. *Message .create(Application *, Message *)   (from Application)*
   7. *Group QuickFix.Message.getGroup(UInt32, Group)*
   8. *String QuickFix.Group.getField(Int32)*
   9. *MDEntrySize
   QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDEntrySize()*
   10. *MDEntryPx
   QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDEntryPx()*
   11. *MDEntryType
   QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDEntryType()*
   12. *NoMDEntries QuickFix42.MarketDataIncrementalRefresh.getNoMDEntries()
   *
   13. *MDEntryPositionNo
   QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDEntryPositionNo()
   *
   14. *MDUpdateAction
   QuickFix42.MarketDataIncrementalRefresh.NoMDEntries.getMDUpdateAction()*
   15. *Void QuickFix42.MarketDataIncrementalRefresh.NoMDEntries..ctor()*
   16. *UtcTimeStamp * .getCreationTime(MessageStore *, UtcTimeStamp *)
   (from MessageStore)*
   17. *MDReqID QuickFix42.MarketDataIncrementalRefresh.getMDReqID()*
   18. *Boolean QuickFix42.MarketDataIncrementalRefresh.isSetNoMDEntries()*
   19. *Void System.Windows.Forms.TextBoxBase.AppendText(String)*
   20. *Object System.Delegate.DynamicInvokeImpl(Object [])*



Something else:
Is there a way to totally disable the Dictionary check even with repeating
group, like I have 2 machines that I control, I already run them with the
dictionary enable and everything is fine, now I want to run them without the
dictionary check as I know those machines won't change.....

Thanks

Wil

On Wed, Jun 23, 2010 at 5:48 PM, Hei Chan <str...@ya...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi,
>
> I just wonder whether anyone has compared the performance of the latest
> quickfix/C++ 1.13.3 with 1.12.4.
>
> With 1.12.4 (with a small modification -- added support to set send buffer
> size), it seems to be faster than 1.13.3 during my ping test:
> - A server logs the timestamp and sends me a "ping" FIX message.
> - My server replies and the server logs the timestamp when it receives my
> reply.
>
> The ping time increased from 2.2275ms to 2.65833ms out of 120 pings within
> an hour.
>
> Although I understand that it is not a very accurate measure (since the
> time isn't logged in microsecond and # of samples are few), it roughly
> indicates some performance degradation.
>
> I am not saying that there must be a performance degradation...
>
> But I am curious whether anyone on the list can share some stats...
>
> Thanks in advance.
>
>
> Cheers,
> Hei
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>

Re: [Quickfix-developers] Help required

[Grant B. <gbi...@co...>]

QuickFIX/J has their own mailing list.  You should send your question there.
http://quickfixj.org/support/

This mailing list is for the C++ version.

-Grant

On Sun, Sep 12, 2010 at 1:44 AM, munna Bai <are...@ya...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> Dear All
>
> I am new to QuickfixJ, I have developed a small Initiator & Acceptor fix
> engine and when i am trying to send a message, I am getting *
> "quickfix.SessionNotFound*" Exception error, can some body explain to
> rectify this error.
>
> Thank you in advance for your guidance and assistance.
>
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
>
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] Hekp required

[munna B. <are...@ya...>]

Dear All
 
I am new to QuickfixJ, I have developed a small Initiator & Acceptor fix engine and when i am trying to send a message, I am getting "quickfix.SessionNotFound" Exception error, can some body explain to rectify this error. 
 
Thank you in advance for your guidance and assistance.