Performance of term_to_binary vs Bbinary_to_term

[Richard O'Keefe]

This is indeed a little curious.  I have a Smalltalk library that provides
a transport format for an extension of JSON.  For that, encoding large
structures takes about 1.8 times longer than decoding them, but they were
designed to be very easy to decode.  The Erlang external format looks to
be designed for easy decoding too, and I would expect encoding to have to
work harder than decoding (which of several ways to encode an atom, is a
list a string, &c, whereas the decoder is *told*).

If the time taken by binary_to_term/1 is a problem for you, it might be
worth digging into the C code to find out what is going on.

On Tue, 8 Jun 2021 at 00:25, Valentin Micic <v@REDACTED> wrote:

> Hmmm… I realised that my previous email may be seen as a comment rather
> than a question, so let me ask the question clearly.
>
> Given that binary_to_term/1 is about two orders of magnitude slower than
> term_to_binary/1, is there anyone out there that may have a reasonable
> explanation for that?
>
> Kind regards
>
> V/
>
> On 06 Jun 2021, at 02:07, Valentin Micic <v@REDACTED> wrote:
>
> Hi all,
>
> I did some performance measurement recently that included conversion of an
> arbitrary erlang term to its external binary representation via
> term_to_binary/1, as well as reversing the result using binary_to_term/1.
>
> I’ve noticed that term_to_binary/1 is significantly faster than
> binary_to_term/1.
>
> Also, I’ve observed that binary_to_term/1 performance gets considerably
> worse as complexity of specified term increases, whilst term_to_binary/1
> maintains (more-less) steady performance.
>
> (cig@REDACTED)40> tconvert:run( a, 10000000 ).
>
> term_to_binary/1 RETURN VALUE:<<131,100,0,1,97>>
> REQUEST COUNT:10000000
> ELAPSED TIME (usec):97070
> TIME PER REQUEST (usec): 0.009707
> PROJECTED RATE (req/sec): *103018440*.30081384
>
> binary_to_term/1 RETURN VALUE:a
> REQUEST COUNT:10000000
> ELAPSED TIME (usec):3383483
> TIME PER REQUEST (usec): 0.3383483
> PROJECTED RATE (req/sec): *2955534*.2822765773
> ok
>
> (cig@REDACTED)41> tconvert:run( {a,<<1,2,3>>, b, [1,2,3], c, {1,2,3},
> d, #{a=>1, b=>2, c=>3}}, 10000000 ).
>
> term_to_binary/1 RETURN
> VALUE:<<131,104,8,100,0,1,97,109,0,0,0,3,1,2,3,100,0,1,
>
> 98,107,0,3,1,2,3,100,0,1,99,104,3,97,1,97,2,97,
>
> 3,100,0,1,100,116,0,0,0,3,100,0,1,97,97,1,100,
>                                 0,1,98,97,2,100,0,1,99,97,3>>
> REQUEST COUNT:10000000
> ELAPSED TIME (usec):97307
> TIME PER REQUEST (usec): 0.0097307
> PROJECTED RATE (req/sec): *102767529*.57135664
>
> binary_to_term/1 RETURN VALUE:{a,<<1,2,3>>,
>                                  b,
>                                  [1,2,3],
>                                  c,
>                                  {1,2,3},
>                                  d,
>                                  #{a => 1,b => 2,c => 3}}
> REQUEST COUNT:10000000
> ELAPSED TIME (usec):8747426
> TIME PER REQUEST (usec): 0.8747426
> PROJECTED RATE (req/sec): *1143193*.4377038456
> ok
>
>
>
> I’ve performed testing on R21.1.
> Any thoughts?
>
> V/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210609/933e2ca9/attachment.htm>