4 ms·

Looks good. For those of us shopping around, what advantages does Jsmn have over yajl?

pjscott 14y ago
It does no runtime memory allocation, and since it doesn't depend on libc and has a very small size, it can be used on highly resource-constrained embedded processors.
- revelation 14y ago
  Sorry, but no. Shuffling around strings is all fine when you're writing Javascript and have GHz and GB of RAM at your disposal, but that stuff just doesn't fly when you need to conserve RAM and especially need to have easily determined time and space constraints. JSON just doesn't fit that profile. Neat implementation, but don't give the impression that any of this would help with embedded.
  - sillysaurus 14y ago
    Why wouldn't this help with embedded? Are you saying it's never a good idea to use JSON for data transport within any embedded system? That would be a bold claim.
    - revelation 14y ago
      highly resource-constrained embedded processors For me, that means code space and RAM measured in kilobytes, cycles in MHz. Most people don't realize that serializing data (most importantly, floating point numbers) to strings is a complicated and time-intensive matter. Even a limited printf implementation can easily cost you many kilobytes. Not to mention it introduces you to C's most special hell: variable length memory blocks containing strings. The one thing that embedded gives you is a lot of control about your computing environment. Just sending around binary data is a very viable thing to do under these conditions. Not so for JSON; its single biggest selling point is that you can use it in every platform out there. Its the oldest tradeoff: giving up flexibility allows you to use more constrained processors (and save money).
      - sillysaurus 14y ago
        Excellent points. Thank you for transmitting your wisdom.
  - bryanlarsen 14y ago
    Embedded machines these days often run at a gigahertz (or most of it), and have enough RAM to run Linux. Shuffling around strings is not a problem.
    - revelation 14y ago
      What embedded machines are we talking about? The processor in your smartphone is not resource constrained, its just power constrained. Thats a very different tradeoff.
  - eungyu 14y ago
    Even with GHz and GB of RAM, I've seen enough JSON C parsers which leaks memory over time. There are other issues like how efficient is the memory manager (either malloc or others), etc. IMO, getting rid of memory allocation is definitely an shift toward making a reliable json parser.
  - georgemcbay 14y ago
    "embedded" is a big market and isn't always constrained to be hard-realtime. I spent years as an "embedded" developer at chumby industries and ended up having to use JSON fairly frequently. Sometimes you don't get to choose what the source format is because you're consuming someone else's data feed, and if all they offer is JSON, you parse JSON. Also, on a 400-ish mhz ARM with 64 MB of RAM parsing reasonably sized JSON data is no big deal in native code. You need to further qualify your comments beyond just "embedded" because what you're now talking about (very low mhz, KB of RAM) is a niche within the larger embedded world.
  - Derbasti 14y ago
    We have successfully used Lua on a Blackfin processor in one embedded project. It worked just fine as long as you did not use it for real-time tasks.
  - nightski 14y ago
    I worked on a team that created embedded flight data recorders for U.S. Army helicopters that used JSON as a configuration format.
  - pjscott 14y ago
    Are you willing to categorically claim that there is not now, and never will be, a situation in which someone must process JSON and would prefer to do so with an extremely wimpy chip? And by "extremely wimpy" I mean the same thing you do: clock speeds measured in single- or double-digit MHz, code on something like NOR flash, and maybe a kilobyte or two of RAM if you're lucky. Sure, it sounds like a bad idea, but it wouldn't be the first time someone has had to do something crazy for compatibility with someone else's stuff.

It does no runtime memory allocation, and since it doesn't depend on libc and has a very small size, it can be used on highly resource-constrained embedded processors.

revelation 14y ago
Sorry, but no. Shuffling around strings is all fine when you're writing Javascript and have GHz and GB of RAM at your disposal, but that stuff just doesn't fly when you need to conserve RAM and especially need to have easily determined time and space constraints. JSON just doesn't fit that profile. Neat implementation, but don't give the impression that any of this would help with embedded.
- sillysaurus 14y ago
  Why wouldn't this help with embedded? Are you saying it's never a good idea to use JSON for data transport within any embedded system? That would be a bold claim.
  - revelation 14y ago
    highly resource-constrained embedded processors For me, that means code space and RAM measured in kilobytes, cycles in MHz. Most people don't realize that serializing data (most importantly, floating point numbers) to strings is a complicated and time-intensive matter. Even a limited printf implementation can easily cost you many kilobytes. Not to mention it introduces you to C's most special hell: variable length memory blocks containing strings. The one thing that embedded gives you is a lot of control about your computing environment. Just sending around binary data is a very viable thing to do under these conditions. Not so for JSON; its single biggest selling point is that you can use it in every platform out there. Its the oldest tradeoff: giving up flexibility allows you to use more constrained processors (and save money).
    - sillysaurus 14y ago
      Excellent points. Thank you for transmitting your wisdom.
- bryanlarsen 14y ago
  Embedded machines these days often run at a gigahertz (or most of it), and have enough RAM to run Linux. Shuffling around strings is not a problem.
  - revelation 14y ago
    What embedded machines are we talking about? The processor in your smartphone is not resource constrained, its just power constrained. Thats a very different tradeoff.
- eungyu 14y ago
  Even with GHz and GB of RAM, I've seen enough JSON C parsers which leaks memory over time. There are other issues like how efficient is the memory manager (either malloc or others), etc. IMO, getting rid of memory allocation is definitely an shift toward making a reliable json parser.
- georgemcbay 14y ago
  "embedded" is a big market and isn't always constrained to be hard-realtime. I spent years as an "embedded" developer at chumby industries and ended up having to use JSON fairly frequently. Sometimes you don't get to choose what the source format is because you're consuming someone else's data feed, and if all they offer is JSON, you parse JSON. Also, on a 400-ish mhz ARM with 64 MB of RAM parsing reasonably sized JSON data is no big deal in native code. You need to further qualify your comments beyond just "embedded" because what you're now talking about (very low mhz, KB of RAM) is a niche within the larger embedded world.
- Derbasti 14y ago
  We have successfully used Lua on a Blackfin processor in one embedded project. It worked just fine as long as you did not use it for real-time tasks.
- nightski 14y ago
  I worked on a team that created embedded flight data recorders for U.S. Army helicopters that used JSON as a configuration format.
- pjscott 14y ago
  Are you willing to categorically claim that there is not now, and never will be, a situation in which someone must process JSON and would prefer to do so with an extremely wimpy chip? And by "extremely wimpy" I mean the same thing you do: clock speeds measured in single- or double-digit MHz, code on something like NOR flash, and maybe a kilobyte or two of RAM if you're lucky. Sure, it sounds like a bad idea, but it wouldn't be the first time someone has had to do something crazy for compatibility with someone else's stuff.