[
https://issues.apache.org/jira/browse/BEAM-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16734374#comment-16734374
]
Robert Burke commented on BEAM-3580:
------------------------------------
You're right though, a dedicated custom coder for strings would resolve this.
In principle this would also be solvable through the User Defined Coders work.
An alternative work around would be to do the converters, but those are likely
unnecessary altogether if there was a dedicated coder for strings which would
avoid using the converts on all the paths.
That can be fixed by adding conversions prior to the invocation of the combine
operations which isn't currently done via the invoker in all instances (such as
the binary merge fast path),
See here:
[https://github.com/apache/beam/blob/master/sdks/go/pkg/beam/core/runtime/exec/fn.go#L132]
Note: I'm likely going to be changing the combines soon so the code generator
will be able to speed up combines for the AddInput and MergeAccumulators cases.
> Do not use Go BytesCoder to encode string
> -----------------------------------------
>
> Key: BEAM-3580
> URL: https://issues.apache.org/jira/browse/BEAM-3580
> Project: Beam
> Issue Type: Bug
> Components: sdk-go
> Reporter: Henning Rohde
> Priority: Major
>
> We should not use the same built-in coder for two different types. It creates
> the need for conversions at inopportune times in the runtime.
>
> One option would be to a custom coder that shares encoding with bytes, given
> that bytes are length prefixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
