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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Per Msg/Field Features #14

Open
kevinconaway opened this issue Jul 1, 2021 · 2 comments
Open

Per Msg/Field Features #14

kevinconaway opened this issue Jul 1, 2021 · 2 comments
Labels
question Further information is requested

Comments

@kevinconaway
Copy link

馃憢

Are there any plans to support adding features per-msg or per-field?

For example, for some of our string or []byte fields, we prefer to unmarshal them as "unsafe" so as to avoid an allocation if we don't plan to keep the data in memory past the lifetime of the original message.

I was thinking that type of behavior could be added as an annotation in the proto, similar to how the extensions in gogo currently work.

Is that something that is 1.) feasible with this project 2.) something that you would be interested in?

If so, I could try to come up with a POC

Thanks

@nockty
Copy link
Contributor

nockty commented Sep 12, 2023

Hello @kevinconaway! I think ultimately there are two things that may actually be decoupled:

  1. add support for unsafe casting of string and []byte fields;
  2. have per-message / per-field features.

I think (1) is definitely interesting, but I would be curious about use cases for (2). Could you provide some?

Typically, for (1), we could think of adding an unsafe feature providing unsafe methods to unmarshal messages, which doesn't need (2). This would affect all fields of the message, which should be OK, shouldn't it? Presumably, the lifetime for all fields of the message should be the same? In my mind at least, when using memory pooling for instance, we release bytes for the whole message at the same time, but I could be missing some other use case. (I'm not familiar with all extensions from gogo.)

@nockty nockty added the question Further information is requested label Sep 12, 2023
@kevinconaway
Copy link
Author

we could think of adding an unsafe feature providing unsafe methods to unmarshal messages, which doesn't need (2). This would affect all fields of the message, which should be OK, shouldn't it?

Not particularly for our use case. Our messages tend to have a lot of string data and most of them should be un-marshaled safely. It is only for a handful of fields that we opt to unmarshal them in an unsafe manner.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants