4 ms·

I think people say that as they give disproportional weight to the fact it's text-based, while ignoring how astoundingly simple and linear it is to write and re

I think people say that as they give disproportional weight to the fact it's text-based, while ignoring how astoundingly simple and linear it is to write and read. The only way to nudge the needle is to start exchanging direct memory dumps, which is what ProtoBuff and the like do. But this is clearly only for very specific use.

riku_iki 3y ago
> while ignoring how astoundingly simple and linear it is to write and read. code maybe simple, but you have lots of performance penalties: resolving field keys, you need to construct some complicated data structures through memory allocations, which is expensive. > to start exchanging direct memory dumps, which is what ProtoBuff and the like do Protobuff actually is doing parsing, it is just binary format. What you describing is more like Flatbuffer. > But this is clearly only for very specific use. yes, specific use is high performance computations )
- 3cats-in-a-coat 3y ago
  Resolving what keys? JSON has keyval sequences ("objects") but what you do with them is entirely up to you. In a streaming reader you can do your job without ever creating maps or dehydrating objects. Plus no one makes people use objects in JSON. If you can send a tuple of fields as an array... then send an array.
  - riku_iki 3y ago
    > In a streaming reader you can do your job without ever creating maps or dehydrating objects. but you need some logic which will check that key is what you want to process, and also do various type transformation (e.g. json string to long). > Plus no one makes people use objects in JSON. If you can send a tuple of fields as an array... then send an array. then this shouldn't be called JSON parsing anymore.
    - 3cats-in-a-coat 3y ago
      The "logic" to match a key is not slow. Your CPU can parse hundreds of keys while waiting for the next keyval sequence to be loaded from RAM. As for whether you must stuff everything in objects for it to be JSON, I mean that makes no sense. JSON arrays are also JSON. And JSON scalars are also JSON. If this argument requires we deliberately go out of our way to be dumb, then it's a bad argument. I'm writing a platform which has a JSON-like format for message exchange and I realized early on that in serialized data, maps are at best nominal. You process everything serially (hence the word serialization). It's a stream of tokens. The fact some tokens are marked as keys and some as values is something that can be useful to communicate intent, but it doesn't mandate how you utilize it. Everything else is just prejudices and biases, such as "maps take resources to allocate". JSON doesn't force you to build maps when you have an object. Point in the spec where JSON mandates how you must store the parsed results of a JSON object. Should it be a hashmap? A b-tree? A linked list? A tuple? Irrelevant.
      - riku_iki 3y ago
        > The "logic" to match a key is not slow. Your CPU can parse hundreds of keys while waiting for the next keyval sequence to be loaded from RAM. RAM on my computer works with pages loaded into CPU cache. Rants, personal attacks, handwavings are ignored.
        3cats-in-a-coat 3y ago
        No, pages are not loaded in cache. Cache lines are. RAM pages are typically 4kb, and cache lines are most commonly 64 bytes. This means you have 64 cache lines per RAM page. And this entire detour has no relevance to what I said in the first place, which still stands. But you know, someone was wrong on the Internet.
        riku_iki 3y ago
        > RAM pages I didn't say "RAM pages", well vectorrized code can dump MBs of data preemptively into cache, instead of reading "next keyval sequence" each time. > And this entire detour has no relevance to what I said in the first place, or you just don't understand such relevance.

riku_iki 3y ago

> while ignoring how astoundingly simple and linear it is to write and read. code maybe simple, but you have lots of performance penalties: resolving field keys, you need to construct some complicated data structures through memory allocations, which is expensive. > to start exchanging direct memory dumps, which is what ProtoBuff and the like do Protobuff actually is doing parsing, it is just binary format. What you describing is more like Flatbuffer. > But this is clearly only for very specific use. yes, specific use is high performance computations )

3cats-in-a-coat 3y ago
Resolving what keys? JSON has keyval sequences ("objects") but what you do with them is entirely up to you. In a streaming reader you can do your job without ever creating maps or dehydrating objects. Plus no one makes people use objects in JSON. If you can send a tuple of fields as an array... then send an array.
- riku_iki 3y ago
  > In a streaming reader you can do your job without ever creating maps or dehydrating objects. but you need some logic which will check that key is what you want to process, and also do various type transformation (e.g. json string to long). > Plus no one makes people use objects in JSON. If you can send a tuple of fields as an array... then send an array. then this shouldn't be called JSON parsing anymore.
  - 3cats-in-a-coat 3y ago
    The "logic" to match a key is not slow. Your CPU can parse hundreds of keys while waiting for the next keyval sequence to be loaded from RAM. As for whether you must stuff everything in objects for it to be JSON, I mean that makes no sense. JSON arrays are also JSON. And JSON scalars are also JSON. If this argument requires we deliberately go out of our way to be dumb, then it's a bad argument. I'm writing a platform which has a JSON-like format for message exchange and I realized early on that in serialized data, maps are at best nominal. You process everything serially (hence the word serialization). It's a stream of tokens. The fact some tokens are marked as keys and some as values is something that can be useful to communicate intent, but it doesn't mandate how you utilize it. Everything else is just prejudices and biases, such as "maps take resources to allocate". JSON doesn't force you to build maps when you have an object. Point in the spec where JSON mandates how you must store the parsed results of a JSON object. Should it be a hashmap? A b-tree? A linked list? A tuple? Irrelevant.
    - riku_iki 3y ago
      > The "logic" to match a key is not slow. Your CPU can parse hundreds of keys while waiting for the next keyval sequence to be loaded from RAM. RAM on my computer works with pages loaded into CPU cache. Rants, personal attacks, handwavings are ignored.
      - 3cats-in-a-coat 3y ago
        No, pages are not loaded in cache. Cache lines are. RAM pages are typically 4kb, and cache lines are most commonly 64 bytes. This means you have 64 cache lines per RAM page. And this entire detour has no relevance to what I said in the first place, which still stands. But you know, someone was wrong on the Internet.
        riku_iki 3y ago
        > RAM pages I didn't say "RAM pages", well vectorrized code can dump MBs of data preemptively into cache, instead of reading "next keyval sequence" each time. > And this entire detour has no relevance to what I said in the first place, or you just don't understand such relevance.