John Keiser

> I do think you make a good case against having the code embedded in the main simdjson base, If it wasn't clear, I actually think the core ideas have...

In my opinion, the best thing you could do right now, both to get a feel for your API, and to check your actual performance, is integrate your code into...

> > In my opinion, the best thing you could do right now, both to get a feel for your API > > I'm working on that and setting up...

It's worth noting that uint64_t [is available on Arduino](https://forum.arduino.cc/index.php?topic=134253.msg1010365#msg1010365) and seems like it works, even though it's likely implemented using 32-bit operations.

As far as space efficiency, it's worth noting that On Demand in simdjson allocates two buffers, which total 5x the size of the JSON text: a "structural index" buffer 4x...

> Oooh gosh, that's not really feasible for bulk loading gigabytes is it? - which is part of why i built what i built. I wonder if there's a compromise...

The main reason 64-bit matters is that simdjson's external API supports 64-bit numbers, and you'd have more work to do if you had to change the API itself. If arduino...

> Okay I think I get that. You're just using branchlessness in every place you can to keep branch mispredictions down. And then you're using SIMD in places to cover...

Others here know the specifics better than I, but remember the *reason* branch misprediction is bad: the processor has been running ahead executing instructions, and just found out it executed...

For what it's worth, I wondered the exact same thing when I started messing with this project :)