Performance vs. `store`

[raehik]

I'm in the middle of replacing some low level serializing code. I mostly finished swapping to store, then found your ptr-poker library and noted it's a fair amount simpler (no parsing) and is used for efficient JSON serialization, which I was playing with.

Would you be able to compare performance with store? It seems the most related package to yours, slightly older, lots more code. Same idea throughout, but ptr-poker carries around less state and has a classic monoidal interface rather than store's monadic one, and store has a funky Size type which may "explicitly" ignore the argument (perhaps this lends itself to optimizations?).

[nikita-volkov]

Hey!

Thanks for noticing these details :)

I think it would be best to add the lib to the community benchmark: https://github.com/haskell-perf/serialization. Not sure how soon I'll get the time to do that. Would be great to get help.

[raehik]

Thank you for writing this package! Even after trawling through other low-level serializers I've learned a ton reading through this and your jsonifier.

I know of three benchmark projects on GitHub:

• that one, discusses store https://github.com/haskell-perf/serialization
• recent, limited, discusses mason https://github.com/andrewthad/bytes-builder-shootout
• old https://github.com/haskell-perf/strict-bytestring-builders

That community serialization benchmark seems great and well worth bringing up to date. But it seems to target automatic serializing+deserializing libraries. mason and ptr-poker are high speed but no generics and no parsing. I'm not sure what to do -- for now I'll make an issue over there.

[nikita-volkov]

The "strict-bytestring-builders" benchmark is actually under my lead and I do agree that this library probably fits best for that one. I guess it's time to bring it up to the latest developments in the community. I'll take a look.

[nikita-volkov]

BTW, if you're interested, I also have a library for deserialization with quite similar ideas, which I haven't yet published on Hackage. The bundled benchmarks show it to perform much better compared to competition including "store". https://github.com/nikita-volkov/peeky-blinders

[raehik]

Ooh! That's cool, I am. Great name :) Feels like it would be superb as one half of a binary/cereal replacement, where you don't care too much about errors, with a generic/TH interface to it. Then ptr-poker or store may handle the other half.

If I might uno reverse you, have you heard of flatparse? It provides a more classic parser combinator interface (monadic, error handling), but similarly stays at the pointer level. Not as performant, but lots of similar ideas and also very young :)

[raehik]

I started on some generics machinery for peeky-blinders at https://github.com/raehik/peeky-blinders/tree/generics since I'm curious about its performance as a binary/cereal/store/even flatparse (though that doesn't have classy interface/generics) replacement. (I know generics aren't always most performant but I don't know TH!).