Re: [protobuf] Status of protobuf-java 2.x / 3.x compatibility

On Mon, Dec 4, 2017 at 9:00 AM, Chris Thunes wrote: > > I'm looking at options for moving some applications that currently depend > on protobuf-java 2.5.0 to a more recent version. This is made complicated > by the fact that we have a mixure of internal and external

Re: [protobuf] Arena idion: garbage collector/ thread syncronization

Hi, thank you very much for your answer. Probably I can create and reset an arena object per request , but in this case (in my understanding) I don't see much gain vs a heap allocation. Also from memory fragmentation I don't see a big difference. My first implementation used std::unique_ptr

Re: [protobuf] Arena idion: garbage collector/ thread syncronization

The most common idiom is that you have a server that just creates one arena per request. When the request comes in, it creates an arena and uses that throughout the processing of the request, and then destroys it once it is done with that request. I think re-using a single Arena in multiple

[protobuf] Status of protobuf-java 2.x / 3.x compatibility

I'm looking at options for moving some applications that currently depend on protobuf-java 2.5.0 to a more recent version. This is made complicated by the fact that we have a mixure of internal and external dependencies (Hadoop & HBase) which depend on protobuf-java. My understanding is that

[protobuf] Migrating groups to nested fields

Hi, My goal is to convert existing proto2 to proto3. Unfortunately, there are group fields. It is not hard to represent them as nested messages. But is wire format compatible for them? Will it be possible to achieve backward compatibility? Regards, Gor. Image already added -- You received