Git Product home page Git Product logo

rust_serialization_benchmark's Introduction

Rust serialization benchmark

The goal of these benchmarks is to provide thorough and complete benchmarks for various rust serialization frameworks.

These benchmarks are a work in progress

These benchmarks are still being developed and pull requests to improve benchmarks are welcome.

Calculate the number of messages per second that can be sent/received with various rust serialization frameworks and compression libraries. Documentation

Format

All tests benchmark the following properties (time or size):

  • Serialize: serialize data into a buffer
  • Deserialize: deserializes a buffer into a normal rust object
  • Size: the size of the buffer when serialized
  • Zlib: the size of the buffer after zlib compression
  • Zstd: the size of the buffer after zstd compression
  • Zstd Time: the time taken to compress the serialized buffer with zstd

Zero-copy deserialization libraries have an additional set of benchmarks:

  • Access: accesses a buffer as structured data
  • Read: runs through a buffer and reads fields out of it
  • Update: updates a buffer as structured data

Some benchmark results may be italicized and followed by an asterisk. Mouse over these for more details on what situation was benchmarked. Other footnotes are located at the bottom.

Last updated: 2024-5-5 14:16:23

Runtime info

rustc version

rustc 1.77.0-nightly (11f32b73e 2024-01-31)
binary: rustc
commit-hash: 11f32b73e0dc9287e305b5b9980d24aecdc8c17f
commit-date: 2024-01-31
host: x86_64-unknown-linux-gnu
release: 1.77.0-nightly
LLVM version: 17.0.6

CPU info

Architecture:                       x86_64
CPU op-mode(s):                     32-bit, 64-bit
Address sizes:                      48 bits physical, 48 bits virtual
Byte Order:                         Little Endian
CPU(s):                             4
On-line CPU(s) list:                0-3
Vendor ID:                          AuthenticAMD
Model name:                         AMD EPYC 7763 64-Core Processor
CPU family:                         25
Model:                              1
Thread(s) per core:                 2
Core(s) per socket:                 2
Socket(s):                          1
Stepping:                           1
BogoMIPS:                           4890.86
Flags:                              fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext invpcid_single vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves clzero xsaveerptr rdpru arat npt nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload umip vaes vpclmulqdq rdpid fsrm
Virtualization:                     AMD-V
Hypervisor vendor:                  Microsoft
Virtualization type:                full
L1d cache:                          64 KiB (2 instances)
L1i cache:                          64 KiB (2 instances)
L2 cache:                           1 MiB (2 instances)
L3 cache:                           32 MiB (1 instance)
NUMA node(s):                       1
NUMA node0 CPU(s):                  0-3
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit:        Not affected
Vulnerability L1tf:                 Not affected
Vulnerability Mds:                  Not affected
Vulnerability Meltdown:             Not affected
Vulnerability Mmio stale data:      Not affected
Vulnerability Retbleed:             Not affected
Vulnerability Spec rstack overflow: Vulnerable: Safe RET, no microcode
Vulnerability Spec store bypass:    Vulnerable
Vulnerability Spectre v1:           Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:           Mitigation; Retpolines, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected
Vulnerability Srbds:                Not affected
Vulnerability Tsx async abort:      Not affected

log

This data set is composed of HTTP request logs that are small and contain many strings.

Raw data

For operations, time per iteration; for size, bytes. Lower is better.

Serialize / deserialize speed and size

Crate Serialize Deserialize Size Zlib Zstd Zstd Time
abomonation 0.7.3 388.30 µs 1.4553 ms* 1705800 520085 413215 6.7601 ms
alkahest 0.1.5 194.88 µs 1045784 454157 389424 6.0234 ms
bilrost 0.1007.0 781.46 µs* 729.54 µs* 3.1793 ms 874632 355446 311723 5.0678 ms
bincode 2.0.0-rc 213.35 µs 2.5771 ms 741295 303944 257153 3.9887 ms
bincode 1.3.3 526.02 µs 2.0283 ms 1045784 373127 311761 4.8509 ms
bitcode 0.6.0 143.54 µs 1.4848 ms 703710 288826 229755 2.4313 ms
borsh 1.3.1 545.68 µs 2.3023 ms 885780 362204 286514 4.5376 ms
bson 2.9.0 2.2942 ms 7.1524 ms 1924682 532821 376270 5.6447 ms
capnp 0.18.13 560.36 µs 1443216 513986 428649 6.7664 ms
cbor4ii 0.3.2 901.08 µs 5.0874 ms 1407835 403440 324081 4.8194 ms
ciborium 0.2.2 3.8650 ms 10.127 ms 1407835 403440 324081 4.8079 ms
databuf 0.5.0 276.38 µs 2.0724 ms 765778 311715 264630 4.1529 ms
dlhn 0.1.6 801.55 µs 2.5024 ms 724953 301446 253629 3.8139 ms
flatbuffers 23.5.26 1.3596 ms 1276368 468539 388832 5.3179 ms
msgpacker 0.4.3 1.1249 ms 2.5537 ms 764996 315291 264898 3.9499 ms
nachricht-serde 0.4.0 5.6261 ms 4.1247 ms 818669 332556 285514 4.4076 ms
nanoserde 0.1.37 258.42 µs 2.0675 ms 1045784 373127 311761 4.5508 ms
parity-scale-codec 3.6.9 701.41 µs 2.1929 ms 765778 311743 264518 4.1486 ms
postcard 1.0.8 418.01 µs 2.2391 ms 724953 302399 253747 3.8084 ms
pot 3.0.0 2.3888 ms 6.5241 ms 971922 372513 304122 4.6931 ms
prost 0.12.4 997.10 µs* 2.5247 ms* 3.3365 ms 884628 363130 315494 5.1536 ms
rkyv 0.7.44 218.24 µs 1.4689 ms* 2.0033 ms* 1011488 383862 333545 5.2316 ms
rmp-serde 1.1.2 1.3028 ms 3.4644 ms 784997 325384 278219 4.2048 ms
ron 0.8.1 14.280 ms 17.159 ms 1607459 449158 349713 6.0514 ms
savefile 0.16.5 205.04 µs 2.1047 ms 1045800 373139 311755 4.7661 ms
serde_bare 0.5.0 674.00 µs 2.1207 ms 765778 311715 264630 3.9158 ms
serde_cbor 0.11.2 2.0219 ms 5.1234 ms 1407835 403440 324081 4.8201 ms
serde_json 1.0.115 3.7372 ms 5.8615 ms 1827461 470560 361090 5.6102 ms
simd-json 0.13.9 2.1384 ms 4.6856 ms 1827461 470560 361090 5.6261 ms
speedy 0.8.7 197.07 µs 1.7735 ms 885780 362204 286514 4.2123 ms
wiring 0.2.1 194.15 µs 1.9633 ms 1045784 337930 276188 3.9432 ms

Zero-copy deserialization speed

Crate Access Read Update
abomonation 0.7.3 22.552 µs* 38.974 µs*
alkahest 0.1.5 1.8548 ns* 24.860 µs*
capnp 0.18.13 78.774 ns* 162.51 µs*
flatbuffers 23.5.26 2.4730 ns* 1.8537 ms* 52.047 µs* 1.9622 ms*
rkyv 0.7.44 1.2364 ns* 525.61 µs* 10.642 µs* 537.43 µs* 9.6032 µs

Comparison

Relative to best. Higher is better.

Serialize / deserialize speed and size

Crate Serialize Deserialize Size Zlib Zstd Zstd Time
abomonation 0.7.3 36.97% 100.00%* 41.25% 55.53% 55.60% 35.97%
alkahest 0.1.5 73.66% 67.29% 63.60% 59.00% 40.36%
bilrost 0.1007.0 18.37%* 19.68%* 45.77% 80.46% 81.26% 73.70% 47.98%
bincode 2.0.0-rc 67.28% 56.47% 94.93% 95.03% 89.35% 60.95%
bincode 1.3.3 27.29% 71.75% 67.29% 77.41% 73.70% 50.12%
bitcode 0.6.0 100.00% 98.01% 100.00% 100.00% 100.00% 100.00%
borsh 1.3.1 26.30% 63.21% 79.45% 79.74% 80.19% 53.58%
bson 2.9.0 6.26% 20.35% 36.56% 54.21% 61.06% 43.07%
capnp 0.18.13 25.62% 48.76% 56.19% 53.60% 35.93%
cbor4ii 0.3.2 15.93% 28.61% 49.99% 71.59% 70.89% 50.45%
ciborium 0.2.2 3.71% 14.37% 49.99% 71.59% 70.89% 50.57%
databuf 0.5.0 51.94% 70.22% 91.89% 92.66% 86.82% 58.54%
dlhn 0.1.6 17.91% 58.16% 97.07% 95.81% 90.59% 63.75%
flatbuffers 23.5.26 10.56% 55.13% 61.64% 59.09% 45.72%
msgpacker 0.4.3 12.76% 56.99% 91.99% 91.61% 86.73% 61.55%
nachricht-serde 0.4.0 2.55% 35.28% 85.96% 86.85% 80.47% 55.16%
nanoserde 0.1.37 55.55% 70.39% 67.29% 77.41% 73.70% 53.43%
parity-scale-codec 3.6.9 20.46% 66.36% 91.89% 92.65% 86.86% 58.61%
postcard 1.0.8 34.34% 64.99% 97.07% 95.51% 90.54% 63.84%
pot 3.0.0 6.01% 22.31% 72.40% 77.53% 75.55% 51.81%
prost 0.12.4 14.40%* 5.69%* 43.62% 79.55% 79.54% 72.82% 47.18%
rkyv 0.7.44 65.77% 99.07%* 72.65%* 69.57% 75.24% 68.88% 46.47%
rmp-serde 1.1.2 11.02% 42.01% 89.64% 88.76% 82.58% 57.82%
ron 0.8.1 1.01% 8.48% 43.78% 64.30% 65.70% 40.18%
savefile 0.16.5 70.01% 69.15% 67.29% 77.40% 73.70% 51.01%
serde_bare 0.5.0 21.30% 68.62% 91.89% 92.66% 86.82% 62.09%
serde_cbor 0.11.2 7.10% 28.40% 49.99% 71.59% 70.89% 50.44%
serde_json 1.0.115 3.84% 24.83% 38.51% 61.38% 63.63% 43.34%
simd-json 0.13.9 6.71% 31.06% 38.51% 61.38% 63.63% 43.21%
speedy 0.8.7 72.84% 82.06% 79.45% 79.74% 80.19% 57.72%
wiring 0.2.1 73.93% 74.13% 67.29% 85.47% 83.19% 61.66%

Zero-copy deserialization speed

Crate Access Read Update
abomonation 0.7.3 0.01%* 27.31%*
alkahest 0.1.5 66.66%* 42.81%*
capnp 0.18.13 1.57%* 6.55%*
flatbuffers 23.5.26 50.00%* 0.00%* 20.45%* 0.54%*
rkyv 0.7.44 100.00%* 0.00%* 100.00%* 1.98%* 100.00%

mesh

This data set is a single mesh. The mesh contains an array of triangles, each of which has three vertices and a normal vector.

Raw data

For operations, time per iteration; for size, bytes. Lower is better.

Serialize / deserialize speed and size

Crate Serialize Deserialize Size Zlib Zstd Zstd Time
abomonation 0.7.3 237.31 µs 238.69 µs* 6000024 5378514 5345891 7.5669 ms
alkahest 0.1.5 148.76 µs 6000008 5378500 5345890 7.5519 ms
bilrost 0.1007.0 6.6664 ms* 8.4840 ms* 10.811 ms 8625005 6443961 6231572 70.842 ms
bincode 2.0.0-rc 423.57 µs 826.88 µs 6000005 5378497 5345897 7.5272 ms
bincode 1.3.3 5.1204 ms 4.9154 ms 6000008 5378500 5345890 7.4247 ms
bitcode 0.6.0 1.4281 ms 595.24 µs 6000006 5182295 4923880 12.597 ms
borsh 1.3.1 6.1719 ms 4.2969 ms 6000004 5378496 5345889 8.1370 ms
bson 2.9.0 44.747 ms 79.430 ms 23013911 9212089 7497811 106.32 ms
capnp 0.18.13 6.1265 ms 14000088 7130367 6051062 80.604 ms
cbor4ii 0.3.2 10.358 ms 48.051 ms 13125016 7524114 6757967 89.390 ms
ciborium 0.2.2 68.655 ms 106.46 ms 13122324 7524660 6759658 90.317 ms
databuf 0.5.0 2.4039 ms 5.2776 ms 6000003 5378495 5345900 8.2054 ms
dlhn 0.1.6 6.3619 ms 5.9113 ms 6000003 5378495 5345900 8.1883 ms
flatbuffers 23.5.26 675.16 µs 6000024 5378434 5345910 7.9826 ms
msgpacker 0.4.3 21.295 ms 8.7475 ms 7500005 6058442 6014337 10.214 ms
nachricht-serde 0.4.0 122.08 ms 27.191 ms 8125037 6493484 6386940 67.833 ms
nanoserde 0.1.37 1.6680 ms 898.59 µs 6000008 5378500 5345890 7.9059 ms
parity-scale-codec 3.6.9 4.8730 ms 3.9882 ms 6000004 5378496 5345889 7.7785 ms
postcard 1.0.8 509.57 µs 1.5993 ms 6000003 5378495 5345900 8.0403 ms
pot 3.0.0 39.371 ms 72.888 ms 10122342 6814618 6852251 81.124 ms
prost 0.12.4 8.0556 ms* 9.4856 ms* 13.894 ms 8750000 6665735 6421871 70.896 ms
rkyv 0.7.44 188.53 µs 199.81 µs* 198.23 µs* 6000008 5378500 5345892 7.8378 ms
rmp-serde 1.1.2 13.957 ms 19.252 ms 8125006 6494876 6391037 106.80 ms
ron 0.8.1 172.32 ms 260.47 ms 22192885 8970395 8138755 148.14 ms
savefile 0.16.5 238.76 µs 237.40 µs 6000024 5378518 5345893 8.8119 ms
serde_bare 0.5.0 6.3359 ms 4.1928 ms 6000003 5378495 5345900 7.9721 ms
serde_cbor 0.11.2 35.183 ms 44.959 ms 13122324 7524660 6759658 90.122 ms
serde_json 1.0.115 89.807 ms 89.601 ms 26192883 9566084 8586741 155.22 ms
simd-json 0.13.9 54.047 ms 74.398 ms 26192883 9566084 8586741 153.13 ms
speedy 0.8.7 239.54 µs 237.56 µs 6000004 5378496 5345889 7.7605 ms
wiring 0.2.1 198.49 µs 318.18 µs 6000008 5378952 5345894 7.9539 ms

Zero-copy deserialization speed

Crate Access Read Update
abomonation 0.7.3 2.1640 ns* 141.69 µs*
alkahest 0.1.5 1.8622 ns* 77.321 µs*
capnp 0.18.13 111.15 ns* 2.1426 ms*
flatbuffers 23.5.26 2.4738 ns* 37.432 ns* 54.120 µs* 77.381 µs*
rkyv 0.7.44 1.2367 ns* 10.533 ns* 46.024 µs* 77.398 µs* 105.56 µs

Comparison

Relative to best. Higher is better.

Serialize / deserialize speed and size

Crate Serialize Deserialize Size Zlib Zstd Zstd Time
abomonation 0.7.3 62.69% 83.05%* 100.00% 96.35% 92.11% 98.12%
alkahest 0.1.5 100.00% 100.00% 96.35% 92.11% 98.32%
bilrost 0.1007.0 2.23%* 1.75%* 1.83% 69.57% 80.42% 79.02% 10.48%
bincode 2.0.0-rc 35.12% 23.97% 100.00% 96.35% 92.11% 98.64%
bincode 1.3.3 2.91% 4.03% 100.00% 96.35% 92.11% 100.00%
bitcode 0.6.0 10.42% 33.30% 100.00% 100.00% 100.00% 58.94%
borsh 1.3.1 2.41% 4.61% 100.00% 96.35% 92.11% 91.25%
bson 2.9.0 0.33% 0.25% 26.07% 56.26% 65.67% 6.98%
capnp 0.18.13 2.43% 42.86% 72.68% 81.37% 9.21%
cbor4ii 0.3.2 1.44% 0.41% 45.71% 68.88% 72.86% 8.31%
ciborium 0.2.2 0.22% 0.19% 45.72% 68.87% 72.84% 8.22%
databuf 0.5.0 6.19% 3.76% 100.00% 96.35% 92.11% 90.49%
dlhn 0.1.6 2.34% 3.35% 100.00% 96.35% 92.11% 90.67%
flatbuffers 23.5.26 22.03% 100.00% 96.35% 92.11% 93.01%
msgpacker 0.4.3 0.70% 2.27% 80.00% 85.54% 81.87% 72.69%
nachricht-serde 0.4.0 0.12% 0.73% 73.85% 79.81% 77.09% 10.95%
nanoserde 0.1.37 8.92% 22.06% 100.00% 96.35% 92.11% 93.91%
parity-scale-codec 3.6.9 3.05% 4.97% 100.00% 96.35% 92.11% 95.45%
postcard 1.0.8 29.19% 12.39% 100.00% 96.35% 92.11% 92.34%
pot 3.0.0 0.38% 0.27% 59.27% 76.05% 71.86% 9.15%
prost 0.12.4 1.85%* 1.57%* 1.43% 68.57% 77.75% 76.67% 10.47%
rkyv 0.7.44 78.91% 99.21%* 100.00%* 100.00% 96.35% 92.11% 94.73%
rmp-serde 1.1.2 1.07% 1.03% 73.85% 79.79% 77.04% 6.95%
ron 0.8.1 0.09% 0.08% 27.04% 57.77% 60.50% 5.01%
savefile 0.16.5 62.31% 83.50% 100.00% 96.35% 92.11% 84.26%
serde_bare 0.5.0 2.35% 4.73% 100.00% 96.35% 92.11% 93.13%
serde_cbor 0.11.2 0.42% 0.44% 45.72% 68.87% 72.84% 8.24%
serde_json 1.0.115 0.17% 0.22% 22.91% 54.17% 57.34% 4.78%
simd-json 0.13.9 0.28% 0.27% 22.91% 54.17% 57.34% 4.85%
speedy 0.8.7 62.10% 83.44% 100.00% 96.35% 92.11% 95.67%
wiring 0.2.1 74.95% 62.30% 100.00% 96.34% 92.11% 93.35%

Zero-copy deserialization speed

Crate Access Read Update
abomonation 0.7.3 57.15%* 32.48%*
alkahest 0.1.5 66.41%* 59.52%*
capnp 0.18.13 1.11%* 2.15%*
flatbuffers 23.5.26 49.99%* 3.30%* 85.04%* 59.48%*
rkyv 0.7.44 100.00%* 11.74%* 100.00%* 59.46%* 100.00%

minecraft_savedata

This data set is composed of Minecraft player saves that contain highly structured data.

Raw data

For operations, time per iteration; for size, bytes. Lower is better.

Serialize / deserialize speed and size

Crate Serialize Deserialize Size Zlib Zstd Zstd Time
abomonation 0.7.3 190.30 µs 1.3067 ms* 1290592 396676 340554 5.2242 ms
alkahest 0.1.5 217.00 µs 667570 325484 320452 3.9407 ms
bilrost 0.1007.0 919.84 µs* 933.43 µs* 3.1748 ms 489348 281173 249546 3.0936 ms
bincode 2.0.0-rc 280.25 µs 2.0781 ms 367413 221291 206273 2.5093 ms
bincode 1.3.3 568.89 µs 1.8111 ms 569975 240525 232423 2.9136 ms
bitcode 0.6.0 127.67 µs 1.2653 ms 327688 200947 182736 749.09 µs
borsh 1.3.1 554.66 µs 1.8282 ms 446595 234236 210008 2.5189 ms
bson 2.9.0 2.8671 ms 8.2837 ms 1619653 502185 328399 4.8488 ms
capnp 0.18.13 455.97 µs 803896 335606 280851 3.9503 ms
cbor4ii 0.3.2 806.83 µs 4.7936 ms 1109831 344745 274514 3.8123 ms
ciborium 0.2.2 3.6626 ms 9.4787 ms 1109821 344751 274526 3.7917 ms
databuf 0.5.0 320.49 µs 1.7279 ms 356311 213062 198488 2.4021 ms
dlhn 0.1.6 782.46 µs 2.6971 ms 366496 220600 205683 2.4993 ms
flatbuffers 23.5.26 3.3549 ms 844168 345696 294015 3.8784 ms
msgpacker 0.4.3 859.11 µs 2.8043 ms 391251 236877 220476 2.6373 ms
nachricht-serde 0.4.0 5.2047 ms 3.8967 ms 449745 252432 231110 2.7897 ms
nanoserde 0.1.37 280.65 µs 1.8807 ms 567975 239930 232419 2.9029 ms
parity-scale-codec 3.6.9 674.76 µs 2.0027 ms 356311 212976 198524 2.4033 ms
postcard 1.0.8 432.82 µs 1.9547 ms 367489 221913 207344 2.4987 ms
pot 3.0.0 2.3221 ms 6.0368 ms 599125 299158 247693 3.1763 ms
prost 0.12.4 1.1301 ms* 2.8041 ms* 3.5518 ms 596811 305319 269310 3.5273 ms
rkyv 0.7.44 300.29 µs 1.2559 ms* 1.7662 ms* 596952 253967 220706 2.6958 ms
rmp-serde 1.1.2 1.3556 ms 3.0010 ms 424533 245214 226188 2.7036 ms
ron 0.8.1 8.1539 ms 17.714 ms 1465223 434935 343338 5.8713 ms
savefile 0.16.5 223.87 µs 1.8300 ms 566991 239361 232010 2.9037 ms
serde_bare 0.5.0 701.43 µs 2.2270 ms 356311 213062 198488 2.4095 ms
serde_cbor 0.11.2 1.8118 ms 4.7233 ms 1109821 344751 274526 3.8548 ms
serde_json 1.0.115 3.7645 ms 6.8189 ms 1623191 466527 359623 6.0339 ms
simd-json 0.13.9 2.2371 ms 4.5517 ms 1623191 466527 359623 6.0265 ms
speedy 0.8.7 273.04 µs 1.6501 ms 449595 234970 210361 2.5257 ms
wiring 0.2.1 203.15 µs 1.8283 ms 566975 247810 225259 2.9431 ms

Zero-copy deserialization speed

Crate Access Read Update
abomonation 0.7.3 37.083 µs* 37.931 µs*
alkahest 0.1.5 1.8618 ns* 4.6303 µs*
capnp 0.18.13 78.812 ns* 437.77 ns*
flatbuffers 23.5.26 2.4739 ns* 2.1562 ms* 1.3736 µs* 2.1561 ms*
rkyv 0.7.44 1.2368 ns* 498.64 µs* 163.24 ns* 499.85 µs* 953.85 ns

Comparison

Relative to best. Higher is better.

Serialize / deserialize speed and size

Crate Serialize Deserialize Size Zlib Zstd Zstd Time
abomonation 0.7.3 67.09% 96.11%* 25.39% 50.66% 53.66% 14.34%
alkahest 0.1.5 58.83% 49.09% 61.74% 57.02% 19.01%
bilrost 0.1007.0 13.88%* 13.68%* 39.56% 66.96% 71.47% 73.23% 24.21%
bincode 2.0.0-rc 45.56% 60.44% 89.19% 90.81% 88.59% 29.85%
bincode 1.3.3 22.44% 69.34% 57.49% 83.55% 78.62% 25.71%
bitcode 0.6.0 100.00% 99.26% 100.00% 100.00% 100.00% 100.00%
borsh 1.3.1 23.02% 68.70% 73.37% 85.79% 87.01% 29.74%
bson 2.9.0 4.45% 15.16% 20.23% 40.01% 55.64% 15.45%
capnp 0.18.13 28.00% 40.76% 59.88% 65.07% 18.96%
cbor4ii 0.3.2 15.82% 26.20% 29.53% 58.29% 66.57% 19.65%
ciborium 0.2.2 3.49% 13.25% 29.53% 58.29% 66.56% 19.76%
databuf 0.5.0 39.84% 72.68% 91.97% 94.31% 92.06% 31.18%
dlhn 0.1.6 16.32% 46.56% 89.41% 91.09% 88.84% 29.97%
flatbuffers 23.5.26 3.81% 38.82% 58.13% 62.15% 19.31%
msgpacker 0.4.3 14.86% 44.78% 83.75% 84.83% 82.88% 28.40%
nachricht-serde 0.4.0 2.45% 32.23% 72.86% 79.60% 79.07% 26.85%
nanoserde 0.1.37 45.49% 66.78% 57.69% 83.75% 78.62% 25.81%
parity-scale-codec 3.6.9 18.92% 62.71% 91.97% 94.35% 92.05% 31.17%
postcard 1.0.8 29.50% 64.25% 89.17% 90.55% 88.13% 29.98%
pot 3.0.0 5.50% 20.80% 54.69% 67.17% 73.78% 23.58%
prost 0.12.4 11.30%* 4.55%* 35.36% 54.91% 65.82% 67.85% 21.24%
rkyv 0.7.44 42.52% 100.00%* 71.11%* 54.89% 79.12% 82.80% 27.79%
rmp-serde 1.1.2 9.42% 41.85% 77.19% 81.95% 80.79% 27.71%
ron 0.8.1 1.57% 7.09% 22.36% 46.20% 53.22% 12.76%
savefile 0.16.5 57.03% 68.63% 57.79% 83.95% 78.76% 25.80%
serde_bare 0.5.0 18.20% 56.39% 91.97% 94.31% 92.06% 31.09%
serde_cbor 0.11.2 7.05% 26.59% 29.53% 58.29% 66.56% 19.43%
serde_json 1.0.115 3.39% 18.42% 20.19% 43.07% 50.81% 12.41%
simd-json 0.13.9 5.71% 27.59% 20.19% 43.07% 50.81% 12.43%
speedy 0.8.7 46.76% 76.11% 72.89% 85.52% 86.87% 29.66%
wiring 0.2.1 62.85% 68.69% 57.80% 81.09% 81.12% 25.45%

Zero-copy deserialization speed

Crate Access Read Update
abomonation 0.7.3 0.00%* 0.43%*
alkahest 0.1.5 66.43%* 3.53%*
capnp 0.18.13 1.57%* 37.29%*
flatbuffers 23.5.26 49.99%* 0.00%* 11.88%* 0.01%*
rkyv 0.7.44 100.00%* 0.00%* 100.00%* 0.03%* 100.00%

mk48

This data set is composed of mk48.io game updates that contain data with many exploitable patterns and invariants.

Raw data

For operations, time per iteration; for size, bytes. Lower is better.

Serialize / deserialize speed and size

Crate Serialize Deserialize Size Zlib Zstd Zstd Time
abomonation 0.7.3 494.74 µs 2.3138 ms* 2984682 1406960 1270204 14.375 ms
alkahest 0.1.5 736.82 µs 1863391 1234113 1202345 11.492 ms
bilrost 0.1007.0 5.0616 ms* 2.9598 ms* 8.3336 ms 1664428 1264167 1216472 11.787 ms
bincode 2.0.0-rc 704.51 µs 3.6795 ms 1372381 1091486 1037296 9.1873 ms
bincode 1.3.3 3.7819 ms 4.0190 ms 1811011 1115281 1025627 9.9232 ms
bitcode 0.6.0 720.61 µs 2.3067 ms 948499 857321 837658 3.1392 ms
borsh 1.3.1 2.8414 ms 2.9373 ms 1486162 1082357 1013550 9.4999 ms
bson 2.9.0 20.208 ms 43.719 ms 10030880 2833079 1600859 27.279 ms
capnp 0.18.13 2.1595 ms 2664040 1511895 1212087 14.081 ms
cbor4ii 0.3.2 4.2969 ms 17.734 ms 5878791 1655835 1431390 20.954 ms
ciborium 0.2.2 23.167 ms 46.753 ms 5878653 1655791 1431560 21.097 ms
databuf 0.5.0 1.5985 ms 3.5864 ms 1288257 1037579 984337 8.5242 ms
dlhn 0.1.6 5.2027 ms 6.2461 ms 1279599 1052061 1021161 8.2980 ms
flatbuffers 23.5.26 5.1821 ms 2273740 1408408 1235566 12.952 ms
msgpacker 0.4.3 1.9257 ms 4.5374 ms 1424043 1128758 1110156 9.3866 ms
nachricht-serde 0.4.0 30.786 ms 15.580 ms 1728519 1247642 1233323 11.711 ms
nanoserde 0.1.37 1.5142 ms 2.8971 ms 1770477 1108304 1029947 10.032 ms
parity-scale-codec 3.6.9 3.1573 ms 2.9936 ms 1288257 1039269 986510 8.5351 ms
postcard 1.0.8 1.8447 ms 3.9237 ms 1279599 1058243 1016738 8.3967 ms
pot 3.0.0 13.440 ms 30.000 ms 2544810 1447453 1268390 15.334 ms
prost 0.12.4 5.0090 ms* 9.0471 ms* 9.6005 ms 1818378 1307777 1266311 11.576 ms
rkyv 0.7.44 1.2908 ms 2.1606 ms* 2.7791 ms* 2029080 1335117 1158855 12.329 ms
rmp-serde 1.1.2 8.5612 ms 12.153 ms 1703813 1231892 1200208 11.026 ms
ron 0.8.1 36.780 ms 99.490 ms 8476284 2181196 1783971 34.268 ms
savefile 0.16.5 1.0226 ms 2.6249 ms 1750226 1101682 1027827 9.9529 ms
serde_bare 0.5.0 4.9549 ms 4.4516 ms 1288257 1037597 984356 8.6224 ms
serde_cbor 0.11.2 9.6169 ms 21.475 ms 5878653 1655791 1431560 21.123 ms
serde_json 1.0.115 20.185 ms 31.425 ms 9175594 2334253 1800713 34.284 ms
simd-json 0.13.9 11.518 ms 26.311 ms 9175594 2334253 1800713 34.031 ms
speedy 0.8.7 738.68 µs 2.5228 ms 1546963 1093532 1013443 9.9670 ms
wiring 0.2.1 744.35 µs 2.6951 ms 1750210 1129857 1058906 10.503 ms

Zero-copy deserialization speed

Crate Access Read Update
abomonation 0.7.3 66.140 µs* 67.275 µs*
alkahest 0.1.5 1.8551 ns* 627.85 ns*
capnp 0.18.13 79.095 ns* 712.45 ns*
flatbuffers 23.5.26 2.4735 ns* 4.9928 ms* 2.6522 µs* 4.9798 ms*
rkyv 0.7.44 1.2449 ns* 618.32 µs* 489.37 ns* 619.70 µs* 505.40 ns

Comparison

Relative to best. Higher is better.

Serialize / deserialize speed and size

Crate Serialize Deserialize Size Zlib Zstd Zstd Time
abomonation 0.7.3 100.00% 93.38%* 31.78% 60.93% 65.95% 21.84%
alkahest 0.1.5 67.15% 50.90% 69.47% 69.67% 27.32%
bilrost 0.1007.0 9.77%* 16.72%* 25.93% 56.99% 67.82% 68.86% 26.63%
bincode 2.0.0-rc 70.22% 58.72% 69.11% 78.55% 80.75% 34.17%
bincode 1.3.3 13.08% 53.76% 52.37% 76.87% 81.67% 31.63%
bitcode 0.6.0 68.66% 93.67% 100.00% 100.00% 100.00% 100.00%
borsh 1.3.1 17.41% 73.56% 63.82% 79.21% 82.65% 33.04%
bson 2.9.0 2.45% 4.94% 9.46% 30.26% 52.33% 11.51%
capnp 0.18.13 22.91% 35.60% 56.71% 69.11% 22.29%
cbor4ii 0.3.2 11.51% 12.18% 16.13% 51.78% 58.52% 14.98%
ciborium 0.2.2 2.14% 4.62% 16.13% 51.78% 58.51% 14.88%
databuf 0.5.0 30.95% 60.24% 73.63% 82.63% 85.10% 36.83%
dlhn 0.1.6 9.51% 34.59% 74.12% 81.49% 82.03% 37.83%
flatbuffers 23.5.26 9.55% 41.72% 60.87% 67.80% 24.24%
msgpacker 0.4.3 25.69% 47.62% 66.61% 75.95% 75.45% 33.44%
nachricht-serde 0.4.0 1.61% 13.87% 54.87% 68.72% 67.92% 26.81%
nanoserde 0.1.37 32.67% 74.58% 53.57% 77.35% 81.33% 31.29%
parity-scale-codec 3.6.9 15.67% 72.17% 73.63% 82.49% 84.91% 36.78%
postcard 1.0.8 26.82% 55.07% 74.12% 81.01% 82.39% 37.39%
pot 3.0.0 3.68% 7.20% 37.27% 59.23% 66.04% 20.47%
prost 0.12.4 9.88%* 5.47%* 22.51% 52.16% 65.56% 66.15% 27.12%
rkyv 0.7.44 38.33% 100.00%* 77.74%* 46.75% 64.21% 72.28% 25.46%
rmp-serde 1.1.2 5.78% 17.78% 55.67% 69.59% 69.79% 28.47%
ron 0.8.1 1.35% 2.17% 11.19% 39.31% 46.95% 9.16%
savefile 0.16.5 48.38% 82.31% 54.19% 77.82% 81.50% 31.54%
serde_bare 0.5.0 9.98% 48.54% 73.63% 82.63% 85.10% 36.41%
serde_cbor 0.11.2 5.14% 10.06% 16.13% 51.78% 58.51% 14.86%
serde_json 1.0.115 2.45% 6.88% 10.34% 36.73% 46.52% 9.16%
simd-json 0.13.9 4.30% 8.21% 10.34% 36.73% 46.52% 9.22%
speedy 0.8.7 66.98% 85.64% 61.31% 78.40% 82.65% 31.50%
wiring 0.2.1 66.47% 80.17% 54.19% 75.88% 79.11% 29.89%

Zero-copy deserialization speed

Crate Access Read Update
abomonation 0.7.3 0.00%* 0.73%*
alkahest 0.1.5 67.11%* 77.94%*
capnp 0.18.13 1.57%* 68.69%*
flatbuffers 23.5.26 50.33%* 0.00%* 18.45%* 0.01%*
rkyv 0.7.44 100.00%* 0.00%* 100.00%* 0.08%* 100.00%

Footnotes:

* mouse over for situational details

do not provide deserialization capabilities, but the user can write their own

do not support buffer mutation (capnp and flatbuffers may but not for rust)

rust_serialization_benchmark's People

Contributors

8192k avatar ahmedcharles avatar arnabanimesh avatar avl avatar cactter avatar caibear avatar danielalvsaaker avatar djkoloski avatar finnbear avatar gcxfd avatar gloopshlugger avatar jamesmunns avatar kitsuniru avatar knickish avatar licenser avatar louaykamel avatar mumbleskates avatar otake84 avatar quininer avatar reivilibre avatar repi avatar shekhirin avatar vlopes11 avatar zakarumych avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rust_serialization_benchmark's Issues

Apache Avro is not well supported

TL;DR: Apache Avro rust support is bad. Don't bother adding it here. I tried and gave up. If you still want it benchmarked, keep reading and provide feedback.

This is more of a post than an issue. Feel free to close it. I want to at least put it in the issue list, so others can search for it.

Based on my understanding, avro offers very compact encoding. However the rust implementation is purely runtime, therefore offers very poor performance. It would be nice to add it to the benchmarks and test my understanding.

However I gave up due to the following issues:

  • when using avro with serde, it does not support uuid, tuple, or fixed length slice.
  • does not support u32 or u64, though this is not deal breaker, since usage of u32 can be promoted to u64 without space penalty, and u64 is not used in the benchmark.
  • when using avro with serde, option works, but it assumes null is the first variant of union in avro schema.
  • Need to use lazy cell to avoid looking up schema on each serialization. Not sure if this is optimal or standard.
  • when using avro without serde, deserialization gives back an ordered list of fields, I have to either manually build a hash table to lookup field names or assume the order of fields in schema matches the rust definition.

All of the issues can be worked around by building custom logic. But it takes a lot of time and the benchmark feels less authentic.

WIP commit: forrestli74@5a95305

Ideally I should issue these issues with avro or even fix it for them in their repo. But some of them are not easily fixable, some of them have already been tracked or worked on.

Depending on feedback, I might finish writing the custom work around and output some numbers in the benchmark table.

CBOR benchmarks

CBOR is supported through serde so it shouldn't be too hard to get this up and running. Crate is serde_cbor.

Add model data benchmark

Benchmark data of a basic model file. Just a list of triangles, with each triangle containing three vertices and a normal.

Framework hinting standard

Some crates are leaving performance on the table because they're not taking advantage of data invariants. For example:

  • speedy has a number of field attributes that could be used to get smaller / faster integers
  • bitcode can customize several aspects of serialization to exploit data invariants like normalized floats
  • rkyv has several wrapper types that can speed up types with POD arrays

Coming up with a standard for what is and is not admissable for crates to do is important for users to get a realistic view of how they would perform for the majority of users. I think my current position is that we should:

  1. Document exactly which invariants crates are allowed to rely on. This encompasses data ranges and valid values; anything outside of the documented invariants are off-limits.
  2. Allow some minor optimizations. Anything that only requires a little work is OK. My unhelpful metric would be "as much help as you can get from five minutes in a text chat".
  3. Make the benchmarks more comprehensive. If crates are able to turn a benchmark into a memcpy war, then their punishment will be more difficult schemas. This should be the preferred route for foiling metagaming.

@finnbear wrote up an insightful opinion on the matter:

I totally agree the benchmarks should not be gamed in any way and that, to the extent possible, they should represent the performance real users can expect to see!

That said, I think the term "default performance" is entirely subjective because performance depends on:

* How the data are distributed:
  
  * Are are values equally likely or are only a few very small values possible?
  * Do the assumptions made by the format match the distribution of the data?

* Whether optimizations are in place:
  
  * Using enums instead of strings when appropriate
  * Not using unnecessarily large integer types
  * Using available hints when the data distribution is known in advance

As for "default," some formats require:

* creating protocol files

* installing specialized protocol compilers

* manually implementing functions

* running compression algorithms to get competitive file sizes

I think some optimization is a fair ask for users who care about performance. In other words, the recommended way to integrate bitcode is not just to import the crate and derive the traits, but to

* spend a few minutes replacing string with enums where appropriate

* apply domain knowledge of your dataset into minimal width integers and/or range hints

Without the hints, do we get an incorrect general view of bitcode's performance?

There are a few areas in which I think that the benchmarks unrealistically hold back non-hinted bitcode:

* Log
  
  * Using strings instead of numbers/enums for month and timezone (collectively the date) and http method/protocol
  * Using a `u16` when there are only 63 possible response codes
  * Storing a number that maxes out at 100,000,000 in a `u64` helps encodings that do var-int by default

* Mesh
  
  * Randomly generated floats are always between 0 and 1, allowing compression schemes on bytewise formats to take advantage, while not timing the compression in the speed benchmarks.

* Minecraft Save Data
  
  * Using strings instead of enums for item/entity ids, recipes, dimensions

The currently-existing bitcode hints can only recover some of the performance lost due to the above.

TL;DR: To get the most realistic view of bitcode's performance (in order of importance):

1. apply the aforementioned optimizations

2. include total time (serialization _and_ compression) next to compressed sizes for all formats

3. do come up with an explicit policy on hinting/optimizing

4. consistently apply that policy, including with respect to `bitcode`

Prost benchmarks

Prost seems to be a good candidate for the Protocol Buffers implementation to test against. Crate is prost.

Add zlib-compressed size statistic

In many cases, data is zlib-compressed anyway. Adding a statistic on zlib compression may increase or decrease the relative performance of serialization frameworks.

Bincode deserialization could be faster

I noticed that the structs you're using with serde-based deserializers actually have an owned String in them. However, bincode doesn't need to copy strings (I'm not aware about the others).

I'm actually using this in zoxide right now. Here's my struct definitions:

#[derive(Debug, Deserialize, Serialize)]
pub struct DirList<'a>(#[serde(borrow)] Vec<Dir<'a>>);

#[derive(Clone, Debug, Deserialize, Serialize)]
pub struct Dir<'a> {
    #[serde(borrow)]
    pub path: Cow<'a, str>,
    pub rank: Rank,
    pub last_accessed: Epoch,
}

Since the necessary bytes are already in the Vec<u8> that you're trying to deserialize, bincode will just give you a pointer to it instead of copying a whole new String into memory, which is much faster. You can verify this by checking that the deserialized struct actually contains a Cow::Borrowed. You might be able to use a regular &str too, although I'm not sure how bincode would handle different endianness in that case.

P.S. thanks for your fantastic work on rkyv and these benchmarks! Not only is rkyv's performance amazing, it's ideas like structver that would make this a serious contender for anyone wanting a serialization library. I'm currently using a poor man's structver myself, so the idea of rkyv handling this for me sounds absolutely great.

Help with adding ε-serde

We would like to put together a PR adding ε-serde to the suite. Is there some documentation on how to do that, or can you give us some basic guidance and we start from there?

Add validated/unvalidated benchmarks

This is where we start to get into somewhat murky waters. FlatBuffers supports buffer validation, but the dependency needs to get upgraded to 0.8. Cap'n Proto supports validation, but it's lazy so we would need some way of distinguishing that. Maybe splitting the access/read benchmarks into validated/unvalidated for FlatBuffers and rkyv and leaving the Cap'n Proto results as validated.

Add support for simd-json

serde_json is good but simd-json is probably more representative of what end users will actually be comparing against. It's also just a good benchmark to have since it's so popular.

Benchmark including I/O

Adding a benchmark including I/O time would be useful.
Usually serialization/deserialization involves network or disk I/O, and the medium affects the overall performance.

For example, it is unclear from the table in README.md whether rkyv/speedy are faster than prost in real scenarios because the disk read is faster with protobuf. Probably rkyv/speedy are faster than protobuf in LAN. Are they faster in SSD? We do not know.

These additions will help readers make a quick choice on the library.

  • HDD with low IOPS or RPM + Serialization/Deseiralization
  • HDD with high IOPS or RPM + Serialization/Deseiralization
  • SSD + Serialization/Deseiralization
  • Network 10/100/1000 Mbps + Serialization/Deseiralization

Cannot compile on linux

Hi I tried to run this project after installing capnproto and flatbuffers but I'm getting a bunch of compilation errors while calling cargo bench:

error[E0432]: unresolved imports `rust_serialization_benchmark::datasets::log::Log`, `rust_serialization_benchmark::datasets::log::Logs`
  --> benches/bench.rs:41:55
   |
41 |     use rust_serialization_benchmark::datasets::log::{Log, Logs};
   |                                                       ^^^  ^^^^ no `Logs` in `datasets::log`
   |                                                       |
   |                                                       no `Log` in `datasets::log`
   |                                                       help: a similar name exists in the module: `log`

error[E0432]: unresolved import `rust_serialization_benchmark::datasets::log::ArchivedAddress`
   --> benches/bench.rs:140:17
    |
140 |             use rust_serialization_benchmark::datasets::log::ArchivedAddress;
    |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `ArchivedAddress` in `datasets::log`

error[E0432]: unresolved imports `rust_serialization_benchmark::datasets::mesh::Mesh`, `rust_serialization_benchmark::datasets::mesh::Triangle`
   --> benches/bench.rs:188:56
    |
188 |     use rust_serialization_benchmark::datasets::mesh::{Mesh, Triangle};
    |                                                        ^^^^  ^^^^^^^^ no `Triangle` in `datasets::mesh`
    |                                                        |
    |                                                        no `Mesh` in `datasets::mesh`
    |                                                        help: a similar name exists in the module: `mesh`

error[E0432]: unresolved imports `rust_serialization_benchmark::datasets::minecraft_savedata::Player`, `rust_serialization_benchmark::datasets::minecraft_savedata::Players`
   --> benches/bench.rs:316:70
    |
316 |     use rust_serialization_benchmark::datasets::minecraft_savedata::{Player, Players};
    |                                                                      ^^^^^^  ^^^^^^^ no `Players` in `datasets::minecraft_savedata`
    |                                                                      |
    |                                                                      no `Player` in `datasets::minecraft_savedata`

error[E0432]: unresolved import `rust_serialization_benchmark::datasets::minecraft_savedata::ArchivedGameType`
   --> benches/bench.rs:404:17
    |
404 |             use rust_serialization_benchmark::datasets::minecraft_savedata::ArchivedGameType;
    |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `ArchivedGameType` in `datasets::minecraft_savedata`

error[E0433]: failed to resolve: could not find `cp` in `log`
  --> benches/bench.rs:79:70
   |
79 |             .get_root::<rust_serialization_benchmark::datasets::log::cp::logs::Reader>()
   |                                                                      ^^ could not find `cp` in `log`

error[E0433]: failed to resolve: could not find `fb` in `log`
  --> benches/bench.rs:98:62
   |
98 |                 rust_serialization_benchmark::datasets::log::fb::Logs,
   |                                                              ^^ could not find `fb` in `log`

error[E0433]: failed to resolve: could not find `fb` in `log`
   --> benches/bench.rs:108:82
    |
108 |                 flatbuffers::root::<rust_serialization_benchmark::datasets::log::fb::Logs>(bytes)
    |                                                                                  ^^ could not find `fb` in `log`

error[E0433]: failed to resolve: could not find `cp` in `mesh`
   --> benches/bench.rs:224:71
    |
224 |             .get_root::<rust_serialization_benchmark::datasets::mesh::cp::mesh::Reader>()
    |                                                                       ^^ could not find `cp` in `mesh`

error[E0433]: failed to resolve: could not find `fb` in `mesh`
   --> benches/bench.rs:241:63
    |
241 |                 rust_serialization_benchmark::datasets::mesh::fb::Mesh,
    |                                                               ^^ could not find `fb` in `mesh`

error[E0433]: failed to resolve: could not find `fb` in `mesh`
   --> benches/bench.rs:249:83
    |
249 |                 flatbuffers::root::<rust_serialization_benchmark::datasets::mesh::fb::Mesh>(bytes)
    |                                                                                   ^^ could not find `fb` in `mesh`

error[E0433]: failed to resolve: could not find `cp` in `minecraft_savedata`
   --> benches/bench.rs:351:106
    |
351 |         let data = message_reader.get_root::<rust_serialization_benchmark::datasets::minecraft_savedata::cp::players::Reader>().unwrap();
    |                                                                                                          ^^ could not find `cp` in `minecraft_savedata`

error[E0433]: failed to resolve: could not find `fb` in `minecraft_savedata`
   --> benches/bench.rs:367:77
    |
367 |                 rust_serialization_benchmark::datasets::minecraft_savedata::fb::Players,
    |                                                                             ^^ could not find `fb` in `minecraft_savedata`

error[E0433]: failed to resolve: could not find `fb` in `minecraft_savedata`
   --> benches/bench.rs:375:77
    |
375 |                 rust_serialization_benchmark::datasets::minecraft_savedata::fb::Players,
    |                                                                             ^^ could not find `fb` in `minecraft_savedata`

error[E0412]: cannot find type `LogsSchema` in module `rust_serialization_benchmark::datasets::log`
   --> benches/bench.rs:178:79
    |
178 |     data: alkahest::Unpacked<'a, rust_serialization_benchmark::datasets::log::LogsSchema>,
    |                                                                               ^^^^^^^^^^ not found in `rust_serialization_benchmark::datasets::log`

error[E0412]: cannot find type `MeshSchema` in module `rust_serialization_benchmark::datasets::mesh`
   --> benches/bench.rs:308:80
    |
308 |     mesh: alkahest::Unpacked<'a, rust_serialization_benchmark::datasets::mesh::MeshSchema>,
    |                                                                                ^^^^^^^^^^ not found in `rust_serialization_benchmark::datasets::mesh`

error[E0412]: cannot find type `PlayersSchema` in module `rust_serialization_benchmark::datasets::minecraft_savedata`
   --> benches/bench.rs:439:69
    |
439 |         rust_serialization_benchmark::datasets::minecraft_savedata::PlayersSchema,
    |                                                                     ^^^^^^^^^^^^^ not found in `rust_serialization_benchmark::datasets::minecraft_savedata`

error[E0609]: no field `logs` on type `&_`
  --> benches/bench.rs:58:25
   |
58 |         for log in data.logs.iter() {
   |                         ^^^^

error[E0609]: no field `logs` on type `&_`
   --> benches/bench.rs:133:29
    |
133 |             for log in data.logs.iter() {
    |                             ^^^^

error[E0599]: no method named `as_ref` found for struct `Pin<&mut _>` in the current scope
   --> benches/bench.rs:142:30
    |
142 |             for i in 0..logs.as_ref().logs.len() {
    |                              ^^^^^^ method not found in `Pin<&mut _>`
    |
    = note: the method was found for
            - `Pin<P>`
    = note: `logs` is a function, perhaps you wish to call it

error[E0599]: no method named `as_mut` found for struct `Pin<&mut _>` in the current scope
   --> benches/bench.rs:143:36
    |
143 |                 let mut log = logs.as_mut().logs_pin().index_pin(i);
    |                                    ^^^^^^ method not found in `Pin<&mut _>`
    |
    = note: the method was found for
            - `Pin<P>`
    = note: `logs` is a function, perhaps you wish to call it

error[E0609]: no field `triangles` on type `&_`
   --> benches/bench.rs:205:30
    |
205 |         for triangle in data.triangles.iter() {
    |                              ^^^^^^^^^

error[E0609]: no field `triangles` on type `&_`
   --> benches/bench.rs:272:34
    |
272 |             for triangle in mesh.triangles.iter() {
    |                                  ^^^^^^^^^

error[E0599]: no method named `as_ref` found for struct `Pin<&mut _>` in the current scope
   --> benches/bench.rs:277:30
    |
277 |             for i in 0..mesh.as_ref().triangles.len() {
    |                              ^^^^^^ method not found in `Pin<&mut _>`
    |
    = note: the method was found for
            - `Pin<P>`
    = note: `mesh` is a function, perhaps you wish to call it

error[E0599]: no method named `as_mut` found for struct `Pin<&mut _>` in the current scope
   --> benches/bench.rs:278:41
    |
278 |                 let mut triangle = mesh.as_mut().triangles_pin().index_pin(i);
    |                                         ^^^^^^ method not found in `Pin<&mut _>`
    |
    = note: the method was found for
            - `Pin<P>`
    = note: `mesh` is a function, perhaps you wish to call it

error[E0609]: no field `players` on type `&_`
   --> benches/bench.rs:333:28
    |
333 |         for player in data.players.iter() {
    |                            ^^^^^^^

error[E0609]: no field `players` on type `&_`
   --> benches/bench.rs:399:32
    |
399 |             for player in data.players.iter() {
    |                                ^^^^^^^

error[E0599]: no method named `as_ref` found for struct `Pin<&mut _>` in the current scope
   --> benches/bench.rs:406:33
    |
406 |             for i in 0..players.as_ref().players.len() {
    |                                 ^^^^^^ method not found in `Pin<&mut _>`
    |
    = note: the method was found for
            - `Pin<P>`
    = note: `players` is a function, perhaps you wish to call it

error[E0599]: no method named `as_mut` found for struct `Pin<&mut _>` in the current scope
   --> benches/bench.rs:407:42
    |
407 |                 let mut player = players.as_mut().players_pin().index_pin(i);
    |                                          ^^^^^^ method not found in `Pin<&mut _>`
    |
    = note: the method was found for
            - `Pin<P>`
    = note: `players` is a function, perhaps you wish to call it

Some errors have detailed explanations: E0412, E0432, E0433, E0599, E0609.
For more information about an error, try `rustc --explain E0412`.
error: could not compile `rust_serialization_benchmark` due to 29 previous errors
warning: build failed, waiting for other jobs to finish...
warning: `rust_serialization_benchmark` (lib test) generated 81 warnings (81 duplicates)
error: build failed

any idea why?

Compilation failure on MX-LINUX.

Cloned the repo and ran:

$ cargo bench

Machine: AMD64 / Mx-linux.

Had a compilation error due to build.rs script.

  --- stderr                                                                          
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { kind: Failed, description: "Error while trying to execute `capnp compile`: Failed: Permission denied (os erro
r 13).  Please verify that version 0.5.2 or higher of the capnp executable is installed on your system. See https://capnproto.org/install.html" }', build.rs:9:10                             
  stack backtrace:    
...
...
17:     0x563db33e0c69 - build_script_build::main::h48173f533a2f1a5e
                                 at /home/prataprc/tmp/rust_serialization_benchmark/build.rs:3:5 
...
...

Can't decipher the reasoning behind the tools/ directory. Looks like they contain windows executable. Let me know whether I am missing something here. Thanks,

Enable PGO for benchmarks

Enabling profile-guided optimization will provide some numbers that are the best they can be for each framework. It might be worth separating these out from the general numbers so users can get an idea of how much they stand to gain for their efforts.

Add memory and code size benchmarks

It would be useful to see benchmarks on memory usage and code size.

dhat is a Rust crate that provides profiling of heap allocations. One could also use Valgrind. Heap is the most important, but it would also be useful to see stats on stack and static memory.

For code size, I like to follow the instructions on min-sized-rust to remove a lot of the noise in the binary.

I may be able to help with this.

Benchmark `abomonation` deserialization using `.clone()`

This is the intended way to deserialize abomonation structures, so adding a bench that performs the clone but notes that it's just a clone and not anything more complicated would be a good way to add more context to the benchmark.

use simd-json-derive for simd-json benchmarks

simd-json offers its own, optimized derive implementation, it would be nice to use that for the benchmarks instead of the serde ones.

I'll gladly make a PR but I didn't find where the datastructures are defined.

Can't add new framework on MacOS

I am trying to add bincode2 (RC3 currently) but I can't even run a cargo check on MacOS without any changes. It fails to find capnp. Can this repo currently be run on Windows only?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.