Performance of /ui2/cl_json serialization

Question

In the past I used this to return any data structure via SAP RFC:

json = /ui2/cl_json=>serialize( data = <lt_result> 
    pretty_name = /ui2/cl_json=>pretty_mode-low_case ).

This works very well if <lt_result> is small, but for bigger data sets this is slow.

How can I return any data structure via a generic ABAP RFC function module? I use PyRFC, but AFAIK this should not matter much for this question.

Can you give measures for "small/fast" and "big/slow" ? Is it only about the duration of the serialization or only about the duration of the RFC data transfer? — Sandra Rossi, Jan 04 '19 at 20:12
I looked quickly at the code of `/ui2/cl_json`, I think it can be optimized: for instance some things are done several times which could be stored into memory for reuse (method dump_symbols), everywhere the way strings are concatenated is not optimum (cf [rules](https://blogs.sap.com/2016/08/15/performance-trap-in-string-concatenations/)), sometimes intermediate results are stored uselessly in temporary internal tables (append + concatenate lines). So maybe it's worth doing your own code? — Sandra Rossi, Jan 04 '19 at 21:02
@SandraRossi if I return via rfc, then I can create the json in my application outside of sap (python via pyrfc).... I will report my result here. Thank you very much for your detailed investigation. — guettli, Jan 07 '19 at 09:17

score 3 · Accepted Answer · edited Mar 29 '19 at 11:38

3

This may perform better:

DATA(lo_json_writer) = cl_sxml_string_writer=>create( type = if_sxml=>co_xt_json ).

CALL TRANSFORMATION id
                    SOURCE result = <lt_result>
                    RESULT XML lo_json_writer.

ev_json_data = lo_json_writer->get_output( ). " yours export parameter

Taken from official documentation.

edited Mar 29 '19 at 11:38

guettli

25,042
81
346
663

answered Jan 04 '19 at 12:00

Dorad

3,413
2
44
71

can you explain why this should perform better? – guettli Jan 04 '19 at 13:01
I will be back in office on sunday and will make a performance test. Hope someone else can answer you until then. – Dorad Jan 04 '19 at 13:40
2

I am deeply relaxed. No need to hurry. I can wait. – guettli Jan 04 '19 at 13:55
1

@guettli I guess this can be a logic assumption because `/ui2/cl_json` does a serialization with ABAP (byte-code), while `call transformation` does it at kernel level (potentially C code or close), i.e. interpreted byte-code is slower than C code. But this has to be verified, because `call transformation` will do first an XML serialization followed by a conversion into JSON. – Sandra Rossi Jan 04 '19 at 20:04
2

@guettli Finally i made a SAT analyzing. /ui2/cl_json=>serialize performed twice and more worse than the standard syntax. – Dorad Jan 20 '19 at 07:42

score 3 · Answer 2 · edited May 20 '19 at 15:29

If performance is most important for you, then /ui2/cl_json is the wrong choice. While it is an ABAP code and SAP_BASIS 700 compatible syntax. CALL TRANSFORMATION id is better with respect to performance. This is also written in my blog. BTW: I am an author of /ui2/cl_json.

But if it goes about flexibility, comfort, supported data types and desired format, then there is no better solution, for now, comparing to /ui2/cl_json.

Potentially, one can get some better, specialized implementation, using CALL TRANSFORMATION and own XSLT transformation, but it would be already slower then id one and would cost more coding effort.

There are still potential to make /ui2/cl_json faster, by dropping support of lower releases (below 7.40) and using the build in SXML parser for processing the JSON, but that would be some work to do. And I do not have a time / actual request for that.

@Sandra Rossi: I would be happy to apply any performance suggestions for /ui2/cl_json, so if you have concrete examples, please send them to me. Here or in the blog. But please take into consideration that for the current moment, I need to conform to SAP_BASIS 7.00 limits.

Performance of /ui2/cl_json serialization

2 Answers2