Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add MessagePack item serializer and validator #628

Open
wants to merge 27 commits into
base: main
Choose a base branch
from

Conversation

jarmuszz
Copy link
Contributor

@jarmuszz jarmuszz commented Aug 18, 2024

This pull request brings serialization and validation to the msgpack.low module.

Serialization is provided for the outside use through tobinary: Pipe[F, MsgpackItem, Byte] and toNonValidatedBinary: Pipe[F, MsgpackItem, Byte] functions. Akin to how the cbor.low serialization is constructed, serialization without validation can potentialy produce malformed data.

Validation API is also exposed through validated: Pipe[F, MsgpackItem, MsgpackItem].

jarmuszz and others added 12 commits August 11, 2024 15:58
And fix issues found during testing
This change applies only to types in which leading zeros are
insignificant.
The parser mapping ByteVector to MsgpackItem can be seen as a not
injective morphism, that is, there are many ByteVectors that will map to
the same MsgpackItem. Because of this, we cannot possibly guarantee that
`serialize(parse(bs))` is fixpoint for an arbitrary `bs`. However,
currently implemented serializers *are* injective (if we exclude the
Timestamp format family as it can be represented with Extension types)
and so, we can guarantee `serialize(parse(bs)) == bs` if `bs` is a
member of a subset of ByteVector that is emitted by a serializer.

In other words, the following code will be true for any `bs` if
`serialize` is injective and we ignore the Timestamp type family:
```
 val first = serialize(parse(bs))
 val second = serialize(parse(first))
 first == second
```

This test makes sure that the above holds.
@jarmuszz jarmuszz mentioned this pull request Aug 18, 2024
10 tasks
- There was very little performance difference between serializers so
  the `fast` serializer was entirely scrapped.
- The current serializer buffers the output in 4KiB segments before
  emitting it. This change brought a significant speedup.
@jarmuszz
Copy link
Contributor Author

jarmuszz commented Sep 7, 2024

The initial concept of having two serializers was dropped as they ran at a nearly identical time 😃.

These are the current benchmarks on i7-8550U:

Benchmark                                       Mode  Cnt     Score    Error  Units
MsgPackItemSerializerBenchmarks.serialize       avgt   10  3337.518 ± 39.333  us/op
MsgPackItemSerializerBenchmarks.withValidation  avgt   10  5107.575 ± 65.148  us/op

Validation seems to slow things down a bit and I think that maybe it is possible to make it a little faster.

@jarmuszz jarmuszz marked this pull request as ready for review September 7, 2024 11:05
@jarmuszz jarmuszz requested a review from a team as a code owner September 7, 2024 11:05
*
* @param contents buffered [[Chunk]]
*/
private class Out[F[_]](contents: Chunk[Byte]) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the approach, however, this creates a new Out instance for each incoming item. If you run the benchmark with allocation and CPU flame graphs, does it appear to be a bottleneck?

@satabin
Copy link
Member

satabin commented Sep 7, 2024

Thanks a ton for this new contribution. I had a first look at it and left a few comments. But it looks great already. 👏

Copy link
Collaborator

@ybasket ybasket left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good overall 👏 , left only some smaller comments.

Comment on lines +40 to +41
.compile
.string
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm not mistaken, this destroys all chunking, you'll work with one gigantic Chunk – not what real life code should usually do. I think you can simply combine those two streams roughly along the lines of

fs2.io
        .readClassLoaderResource[SyncIO]("twitter_msgpack.txt", 4096)
        .through(fs2.text.utf8.decode)
        .map(str => Chunk.byteVector(ByteVector.fromHex(str).get))
        .unchunks
        .through(fs2.data.msgpack.low.items[SyncIO])
        .compile
        .toList
        .unsafeRunSync()

Comment on lines 26 to 30
class MalformedItemError extends Error("item exceeds the maximum size of it's format")
class MalformedStringError extends MalformedItemError
class MalformedBinError extends MalformedItemError
class MalformedIntError extends MalformedItemError
class MalformedUintError extends MalformedItemError
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are those mapped somewhere? Because as they're within a private[low], users won't have access to them and can't distinguish what failed. Maybe something we'd want to allow? The CSV module has public exception types.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have decided that having separate exception for each type is a bit too granular. Instead, there's a general MsgpackMalformedItemException class since 482bf9e.

Comment on lines +55 to +56
.map(_ => failure(s"Expected error for item ${lhs}"))
.handleError(expect.same(_, rhs))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor: Understanding this bit is a bit tricky as it's unusual to expect the exception. I think redeem could make things more clear:

Suggested change
.map(_ => failure(s"Expected error for item ${lhs}"))
.handleError(expect.same(_, rhs))
.redeem(expect.same(_, rhs), _ => failure(s"Expected error for item ${lhs}"))

The serializer itself was corrected in 041e135
MessagePack Arrays and Maps can hold up to 2^32 - 1 items which is more
than the `Int` type can represent without negative values.
Also drop the `fitsIn` function as we now use `Long`s instead of `Int`s
and so we don't need to compare unsigned values.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants