3 ms·

- complicated and slow to parse - more bloated than binary Not neccessarily, you can write fast compact protocols with text... sending integer and float data

by bullen 6y ago

- complicated and slow to parse - more bloated than binary Not neccessarily, you can write fast compact protocols with text... sending integer and float data as text is not the bottleneck in any system: See my root comment!

kstenerud 6y ago
Floating point numbers are INCREDIBLY complicated to scan (and print). https://code.woboq.org/userspace/glibc/stdio-common/vfscanf-internal.c.html#1903 https://code.woboq.org/userspace/glibc/stdio-common/vfscanf-... Compare that with reading 4 bytes directly into an ieee754 float32. If your messages are short, the benefits of fast codecs are outweighed by the inefficiencies in the communication system (most of your time, processing power and bandwidth are taken up by setting up and tearing down the communication medium). If it takes 7 "administration" packets to send 1 data packet, your codec won't be your bottleneck (in which case you probably don't care about efficiency anyway, and this discussion is not for you).
- bullen 6y ago
  It's not that bad, maybe 10x of nothing. There are much bigger fish to fry when building a large network solution, most prominently getting the thing to be debuggable on live machines!
  - GoblinSlayer 6y ago
    >large network solution You basically restrict networking to big monopolists, like Google, but Google likes binary protocols, like grpc, http2 and quic. And if you have a bug in a complex parser, having text won't help debuggability, because the bug is not in text.
    - bullen 6y ago
      I make my own open-source systems, google is going down a very wrong path recently with defaulting to HTTPS and deprecating HTTP. GRPC, HTTP2, HTTPS, WebSockets, QUIC (HTTP3) are all desperate attempts for job safety. HTTP/1.1 is good enough for 99% of human network requirements. If you are depending on google, make sure you have alternatives because they are VERY unreliable long term.

by bullen 6y ago

kstenerud 6y ago

Floating point numbers are INCREDIBLY complicated to scan (and print). https://code.woboq.org/userspace/glibc/stdio-common/vfscanf-internal.c.html#1903 https://code.woboq.org/userspace/glibc/stdio-common/vfscanf-... Compare that with reading 4 bytes directly into an ieee754 float32. If your messages are short, the benefits of fast codecs are outweighed by the inefficiencies in the communication system (most of your time, processing power and bandwidth are taken up by setting up and tearing down the communication medium). If it takes 7 "administration" packets to send 1 data packet, your codec won't be your bottleneck (in which case you probably don't care about efficiency anyway, and this discussion is not for you).

bullen 6y ago
It's not that bad, maybe 10x of nothing. There are much bigger fish to fry when building a large network solution, most prominently getting the thing to be debuggable on live machines!
- GoblinSlayer 6y ago
  >large network solution You basically restrict networking to big monopolists, like Google, but Google likes binary protocols, like grpc, http2 and quic. And if you have a bug in a complex parser, having text won't help debuggability, because the bug is not in text.
  - bullen 6y ago
    I make my own open-source systems, google is going down a very wrong path recently with defaulting to HTTPS and deprecating HTTP. GRPC, HTTP2, HTTPS, WebSockets, QUIC (HTTP3) are all desperate attempts for job safety. HTTP/1.1 is good enough for 99% of human network requirements. If you are depending on google, make sure you have alternatives because they are VERY unreliable long term.