Open blackgnezdo opened 2 years ago
Sounds like a good change but what do I know about proto-lens internals :)
This makes for suboptimal performance because the user is required to make a copy
I'm not sure if the parsers generated by proto-lens always make copies of ByteStrings, but regardless use of strict ByteString in the generated type definitions doesn't require the underlying bytes to be copied on construction. See for example the implementation of splitAt
Internally, we should store a
Builder
.
This would be a performance loss for many usage patterns.
Proto-lens currently generates an API taking strict
ByteString
forbytes
fields. This makes for suboptimal performance because the user is required to make a copy which is then internally turned into a Builder again for serializing the message inData.ProtoLens.Encoding.Bytes
. To avoid breaking the APIs we should introduce alternative lenses for setting the bytes fields to lazy values (or even aBuilder
). A better API design is welcome.Internally, we should store a
Builder
. We'll automatically applyBuilder.byteString
in generated code. This appears to be efficient so I don't expect any performance regression.There's a possible continuation of this theme for
Text
but I don't have a pressing need and the story is not as clear.@awpr @judah @jinwoo WDYT?