-
-
Notifications
You must be signed in to change notification settings - Fork 27
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
base: main
Are you sure you want to change the base?
Conversation
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.
- 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.
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:
Validation seems to slow things down a bit and I think that maybe it is possible to make it a little faster. |
msgpack/src/main/scala/fs2/data/msgpack/low/internal/ItemSerializer.scala
Outdated
Show resolved
Hide resolved
* | ||
* @param contents buffered [[Chunk]] | ||
*/ | ||
private class Out[F[_]](contents: Chunk[Byte]) { |
There was a problem hiding this comment.
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?
msgpack/src/main/scala/fs2/data/msgpack/low/internal/ItemValidator.scala
Outdated
Show resolved
Hide resolved
Thanks a ton for this new contribution. I had a first look at it and left a few comments. But it looks great already. 👏 |
There was a problem hiding this 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.
.compile | ||
.string |
There was a problem hiding this comment.
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()
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
msgpack/src/main/scala/fs2/data/msgpack/low/internal/ItemSerializer.scala
Outdated
Show resolved
Hide resolved
msgpack/src/main/scala/fs2/data/msgpack/low/internal/ItemSerializer.scala
Outdated
Show resolved
Hide resolved
.map(_ => failure(s"Expected error for item ${lhs}")) | ||
.handleError(expect.same(_, rhs)) |
There was a problem hiding this comment.
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:
.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.
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]
andtoNonValidatedBinary: Pipe[F, MsgpackItem, Byte]
functions. Akin to how thecbor.low
serialization is constructed, serialization without validation can potentialy produce malformed data.Validation API is also exposed through
validated: Pipe[F, MsgpackItem, MsgpackItem]
.