code-anth

code-anth

Hello. I have benchmarked the JSON module ( JSON — Elixir v1.20.4 ) against a few libraries, including Erlang’s :jiffy. I’ve noticed a pattern that I find a bit hard to explain/understand and would like to hear your thoughts on it. Basically, JSON is ~2 times faster than :jiffy when encoding but :jiffy is ~2 times faster in decoding. This makes it quite hard to choose from one library to the other, given that one usually needs both encoding and decoding functionalities.

This is the benchmarking setup I had:

defmodule Benchmark.JsonLibrariesComparison do
  def run(_) do
    experiment()
  end

  def payload(size_kb \\ 1) do
    :crypto.strong_rand_bytes(size_kb * 1024)
    |> Base.encode64()
    |> binary_part(0, size_kb * 1024)
  end

  def experiment() do
    small_payload = payload(30)
    medium_payload = payload(130)
    large_payload = payload(230)

    encode_inputs = %{
      "small (30kb)" => small_payload,
      "medium (130kb)" => medium_payload,
      "large (230kb)" => large_payload
    }

    decode_inputs =
      Map.new(encode_inputs, fn {label, term} ->
        encoded = JSON.encode!(term)
        {label, encoded}
      end)

    Benchee.run(
      %{
        "native encode" => fn binary -> JSON.encode!(binary) end,
        "jiffy encode" => fn binary ->
          IO.iodata_to_binary(:jiffy.encode(binary))
        end
      },
      inputs: encode_inputs,
      warmup: 3,
      time: 10,
      memory_time: 2,
      formatters: [
        {Benchee.Formatters.Console, extended_statistics: true}
      ]
    )

    Benchee.run(
      %{
        "native decode" => fn binary -> JSON.decode(binary) end,
        "jiffy decode" => fn binary -> :jiffy.decode(binary, [:return_maps]) end
      },
      inputs: decode_inputs,
      warmup: 3,
      time: 10,
      memory_time: 2,
      formatters: [
        {Benchee.Formatters.Console, extended_statistics: true}
      ]
    )
  end
end

And these are the benchmarking results:

Operating System: Linux
CPU Information: AMD Ryzen 5 3550H with Radeon Vega Mobile Gfx
Number of Available Cores: 8
Available memory: 13.59 GB
Elixir 1.19.5
Erlang 28.3.1
JIT enabled: true

Benchmark suite executing with the following configuration:
warmup: 3 s
time: 10 s
memory time: 2 s
reduction time: 0 ns
parallel: 1
inputs: large (230kb), medium (130kb), small (30kb)
Estimated total run time: 1 min 30 s
Excluding outliers: false

Benchmarking jiffy encode with input large (230kb) ...
Benchmarking jiffy encode with input medium (130kb) ...
Benchmarking jiffy encode with input small (30kb) ...
Benchmarking native encode with input large (230kb) ...
Benchmarking native encode with input medium (130kb) ...
Benchmarking native encode with input small (30kb) ...
Calculating statistics...
Formatting results...

With input large (230kb)

Name                    ips        average  deviation         median         99th %
native encode        2.29 K      437.46 μs    ±10.12%      429.31 μs      672.61 μs
jiffy encode         1.42 K      703.19 μs    ±13.24%      676.83 μs     1129.40 μs

Comparison:
native encode        2.29 K
jiffy encode         1.42 K - 1.61x slower +265.73 μs

Extended statistics:

Name                  minimum        maximum    sample size                     mode
native encode       383.78 μs     1270.27 μs        22.66 K                419.61 μs
jiffy encode        640.02 μs     3358.87 μs        14.13 K                673.90 μs

Memory usage statistics:

Name             Memory usage
native encode        0.133 KB
jiffy encode          3.40 KB - 25.59x memory usage +3.27 KB

All measurements for memory usage were the same

With input medium (130kb)

Name                    ips        average  deviation         median         99th %
native encode        4.01 K      249.48 μs    ±15.08%      240.11 μs      426.44 μs
jiffy encode         2.45 K      407.65 μs    ±18.41%      389.29 μs      704.10 μs

Comparison:
native encode        4.01 K
jiffy encode         2.45 K - 1.63x slower +158.17 μs

Extended statistics:

Name                  minimum        maximum    sample size                     mode
native encode       215.32 μs     1215.31 μs        39.50 K                238.58 μs
jiffy encode        365.83 μs     3238.25 μs        24.28 K                375.40 μs

Memory usage statistics:

Name             Memory usage
native encode        0.133 KB
jiffy encode          2.62 KB - 19.71x memory usage +2.48 KB

All measurements for memory usage were the same

With input small (30kb)

Name                    ips        average  deviation         median         99th %
native encode       17.03 K       58.74 μs    ±24.40%       55.66 μs      115.45 μs
jiffy encode        10.35 K       96.66 μs    ±19.96%       90.58 μs      156.51 μs

Comparison:
native encode       17.03 K
jiffy encode        10.35 K - 1.65x slower +37.92 μs

Extended statistics:

Name                  minimum        maximum    sample size                     mode
native encode        46.16 μs     2409.24 μs       160.32 K                 55.31 μs
jiffy encode         83.32 μs     2911.81 μs        99.80 K                 90.09 μs

Memory usage statistics:

Name             Memory usage
native encode        0.133 KB
jiffy encode          1.54 KB - 11.59x memory usage +1.41 KB

All measurements for memory usage were the same
Operating System: Linux
CPU Information: AMD Ryzen 5 3550H with Radeon Vega Mobile Gfx
Number of Available Cores: 8
Available memory: 13.59 GB
Elixir 1.19.5
Erlang 28.3.1
JIT enabled: true

Benchmark suite executing with the following configuration:
warmup: 3 s
time: 10 s
memory time: 2 s
reduction time: 0 ns
parallel: 1
inputs: large (230kb), medium (130kb), small (30kb)
Estimated total run time: 1 min 30 s
Excluding outliers: false

Benchmarking jiffy decode with input large (230kb) ...
Benchmarking jiffy decode with input medium (130kb) ...
Benchmarking jiffy decode with input small (30kb) ...
Benchmarking native decode with input large (230kb) ...
Benchmarking native decode with input medium (130kb) ...
Benchmarking native decode with input small (30kb) ...
Calculating statistics...
Formatting results...

With input large (230kb)

Name                    ips        average  deviation         median         99th %
jiffy decode         4.38 K      228.56 μs    ±14.40%      219.09 μs      385.41 μs
native decode        2.39 K      418.64 μs     ±4.11%      416.74 μs      440.77 μs

Comparison:
jiffy decode         4.38 K
native decode        2.39 K - 1.83x slower +190.08 μs

Extended statistics:

Name                  minimum        maximum    sample size                     mode
jiffy decode        212.25 μs     1402.06 μs        42.96 K                218.95 μs
native decode       376.86 μs     2107.66 μs        23.70 K                413.60 μs

Memory usage statistics:

Name             Memory usage
jiffy decode             64 B
native decode           328 B - 5.13x memory usage +264 B

All measurements for memory usage were the same

With input medium (130kb)

Name                    ips        average  deviation         median         99th %
jiffy decode         7.80 K      128.29 μs     ±5.77%      126.48 μs      144.29 μs
native decode        4.16 K      240.63 μs    ±12.97%      234.46 μs      384.16 μs

Comparison:
jiffy decode         7.80 K
native decode        4.16 K - 1.88x slower +112.35 μs

Extended statistics:

Name                  minimum        maximum    sample size                     mode
jiffy decode        119.99 μs     1095.60 μs        75.82 K                126.41 μs
native decode       211.90 μs      943.48 μs        40.94 K                233.76 μs

Memory usage statistics:

Name             Memory usage
jiffy decode             64 B
native decode           328 B - 5.13x memory usage +264 B

All measurements for memory usage were the same

With input small (30kb)

Name                    ips        average  deviation         median         99th %
jiffy decode        27.23 K       36.72 μs    ±42.34%       36.67 μs       47.14 μs
native decode       17.56 K       56.93 μs    ±19.30%       56.01 μs       70.89 μs

Comparison:
jiffy decode        27.23 K
native decode       17.56 K - 1.55x slower +20.21 μs

Extended statistics:

Name                  minimum        maximum    sample size                     mode
jiffy decode         27.17 μs     3489.05 μs       249.05 K                 36.67 μs
native decode        47.63 μs     2833.73 μs       165.92 K                 55.80 μs

Memory usage statistics:

Name             Memory usage
jiffy decode             64 B
native decode           328 B - 5.13x memory usage +264 B

All measurements for memory usage were the same

Any thoughts much appreciated!

Showing Posts 1 to 7

saleyn

saleyn

Feel free to benchmark against glazer.

rhcarvalho

rhcarvalho

What’s your actual use case?

code-anth

code-anth OP

Simplifying the number of JSON libraries currently used in an application. I was hoping to only use JSON, but it seems significantly slower than :jiffy in decoding, hence the question.

rhcarvalho

rhcarvalho

Ah, I see. Using JSON means you have no external dependency. If the performance is good enough, it would be a compelling choice.

I was going to jokingly say you could use JSON.encode and :jiffy.decode :slight_smile:
Best of both. Or not.

I think a problem with those benchmarks might be that they don’t do the same thing your project likely does. You might have differently shaped data, nested maps, lists, short and long strings, etc.

Also, your application performance might depend on other things, such that the choice of JSON library wouldn’t make a difference to the overall performance.

code-anth

code-anth OP

I like the suggestion of using both! :slight_smile:

And of course, you’re right about benchmarks not being like for like. However, they are still benchmarks and the discrepancy between the encode and decode performance is interesting to think about.

garazdawi

garazdawi

Erlang Core Team

The NIF api does not allow the user to parse erlang terms in the same speed as the JIT does, so Erlang/Elixir code written to parse erlang terms and emit binaries is faster. However, when creating Erlang terms NIFs and the JIT are about the same, so here the C code advantage wins.

code-anth

code-anth OP

Ah, thank you! That explains it. I was hoping it was something that could be optimised in the JSON, but it doesn’t sound like it. Thanks!

— All posts loaded —

Where Next? Top

Trending in Thoughts On... Top

code-anth
Hello. I have benchmarked the JSON module ( JSON — Elixir v1.20.4 ) against a few libraries, including Erlang’s :jiffy. I’ve noticed a pa...
New

Other Trending Topics Top

mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve. They are GUI (Emerge) and State management (S...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews