[
https://issues.apache.org/jira/browse/DISPATCH-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854647#comment-16854647
]
Ken Giusti commented on DISPATCH-1352:
--------------------------------------
The first bullet point is similar to something I wanted to do for awhile:
separate the buffer(s) containing the header info (annotations, properties,
etc) from the message body.
The need relates to multi-frame large messages. In that case we (rightly) free
inbound buffers once all data has been sent out all (fanout) links so we don't
have to buffer a potentially huge message.
But even in that case the router still references header info while the message
is being forwarded, so we have to keep those buffers that contain header data
around until we're done with the message.
Maybe we provide some buffer space in the message private structure itself,
large enough to hold a "reasonable" amount of message header stuff (and perhaps
some body as well) and only use qd_buffer_t's when the message size goes beyond
that threshold?
It's Monday and I can't confidently say my caffeine/blood ratio is at the
recommended level so I'm probably overlooking some dreadfully obvious detail
that makes it infeasible.... caveat emptor
> qd_buffer_list_clone cost is dominated by cache misses
> ------------------------------------------------------
>
> Key: DISPATCH-1352
> URL: https://issues.apache.org/jira/browse/DISPATCH-1352
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Routing Engine
> Affects Versions: 1.7.0
> Reporter: Francesco Nigro
> Priority: Major
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> qd_buffer_list_clone on qd_message_copy for
> qd_message_pvt_t.ma_to_override/ma_trace/ma_ingress is dominated by cache
> misses costs:
> * to "allocate" new qd_buffer_t
> * to reference any qd_buffer_t from the source qd_buffer_list_t
> Such cost is the main reason why the core thread is having a very low IPC (<
> 1 istr/cycle) and given the single threaded nature of the router while
> dealing with it, by solving it will bring a huge performance improvement to
> make the router able to scale better.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
