[
https://issues.apache.org/jira/browse/PROTON-2451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18042919#comment-18042919
]
ASF subversion and git services commented on PROTON-2451:
---------------------------------------------------------
Commit b1b9b07a2552c69ad6512d5e272534d26538f692 in qpid-proton's branch
refs/heads/main from Andrew Stitcher
[ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=b1b9b07a2 ]
PROTON-2910: [core] Changed generated code to use better names
The generated code now uses the specs to generate the frame
encode/decode functions, but allows you to specify their names. This
allows the actual code to read a whole lot better.
Also now documented the spec codes at the top of the generate.py code.
I think this doc can still be improved.
(Also removed some holdovers from the initial PROTON-2451 work)
> 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.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]