[
https://issues.apache.org/jira/browse/PROTON-2451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17438851#comment-17438851
]
ASF subversion and git services commented on PROTON-2451:
---------------------------------------------------------
Commit f114a05a8a491797dab514bb58da9364869ba3ec in qpid-proton's branch
refs/heads/main from Andrew Stitcher
[ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=f114a05 ]
PROTON-2451: Don't treat message id/correlation_id as pn_data_t unless we need
to.
Add capability to encode/decode AMQP message id/correlation id directly
to pn_atom_t by introducing a new formatting code 'a'. This avoids going
through the very inefficient pn_data_t unless we really have to.
If the pn_data_t APIs (pn_message_id/pn_message_correlation_id) are not used
then using only the message id/correlation id set/get APIs should be pretty
efficient.
The first time the application gets the pn_data_t from either of the
deprecated old APIs this activates the backwards compatibility mode and
everything becomes slow again. There's no real alternative to this as
these APIs give out a pointer to the messages internal state which can
now be changed by the application directly.
> Reduce (ultimately eliminate) all use of the pn_data_t data structure in AMQP
> frame processing
> ----------------------------------------------------------------------------------------------
>
> Key: PROTON-2451
> URL: https://issues.apache.org/jira/browse/PROTON-2451
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Reporter: Andrew Stitcher
> Assignee: Andrew Stitcher
> Priority: Major
> Fix For: proton-c-0.37.0
>
>
> In current proton protocol processing code make heavy use of the pn_data_t
> data structure for coding and decoding AMQP frames to send and receive.
> Unfortunately the data structure is complex and the code which uses it is not
> very efficient. This means that a lot of CPU is consumed maniputing these
> data structures unnecessarily during the critical path operations of proton.
> During frame processing pn_data_t is not even really necessary as it is only
> used as an intermediary to extract necessary frame parameters out of the
> frames (or as an intermediary to construct the frames from the necessary
> frame parameters.
> This means that is entirely feasible to go directly from/to the parameters
> to/from the frames without using an intermediate pn_data_t at all.
> The most complicated aspect of this and one which will be deferred somewhat
> is that of using non scalar structured data as part of AMQP frames.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
