Since they already implement an unsafeWrap method which breaks immutability
so add DBB support for CIS does not break anything else. I think it is easy
to make the google guys accept the PR. Let's do it :)
2016-02-03 5:58 GMT+08:00 Stack :
> Looks like the boys from pb are doing COS only, not CIS
like flatbuffers.
-Vlad
On Tue, Feb 2, 2016 at 2:04 PM, Enis Söztutar wrote:
> Great. I'll be happy to help / take on the work.
>
> Enis
>
> On Tue, Feb 2, 2016 at 1:58 PM, Stack wrote:
>
> > Looks like the boys from pb are doing COS only, not CIS, and suggest pull
> > request. I'll have a go
Great. I'll be happy to help / take on the work.
Enis
On Tue, Feb 2, 2016 at 1:58 PM, Stack wrote:
> Looks like the boys from pb are doing COS only, not CIS, and suggest pull
> request. I'll have a go unless someone else wants to.
> St.Ack
>
> On Tue, Feb 2, 2016 at 11:41 AM, Enis Söztutar wro
Looks like the boys from pb are doing COS only, not CIS, and suggest pull
request. I'll have a go unless someone else wants to.
St.Ack
On Tue, Feb 2, 2016 at 11:41 AM, Enis Söztutar wrote:
> Google guys over at
> https://github.com/grpc/grpc-java/issues/1054#issuecomment-147295224 are
> saying t
It looks like flatbuffers breaks binary compat. If we are breaking binary
compat then we can look at things other than protobuf descendants.
On Tue, Feb 2, 2016 at 1:14 PM, Stack wrote:
> On Tue, Feb 2, 2016 at 12:16 PM, Enis Söztutar wrote:
>
> > bq. java is second class in flatbuffers).
> > T
On Tue, Feb 2, 2016 at 12:16 PM, Enis Söztutar wrote:
> bq. java is second class in flatbuffers).
> This is an Android project, no? I thought Java is the primary target.
>
> I was looking at this Enis:
https://google.github.io/flatbuffers/flatbuffers_support.html
St.Ack
> On Tue, Feb 2, 2016
I remember talking over capn proto with Stack and a few others a while ago,
when it first got underway. Over the intervening time I think we have seen that
Java support is a second or third order concern for them at best.
I think the most important factor is getting away from copying. Whatever
bq. java is second class in flatbuffers).
This is an Android project, no? I thought Java is the primary target.
On Tue, Feb 2, 2016 at 12:14 PM, Stack wrote:
> On Tue, Feb 2, 2016 at 11:47 AM, Enis Söztutar wrote:
>
> > BTW, we should also be looking at https://google.github.io/flatbuffers/
> o
On Tue, Feb 2, 2016 at 11:47 AM, Enis Söztutar wrote:
> BTW, we should also be looking at https://google.github.io/flatbuffers/ or
> https://capnproto.org/ for serialization as an option. The idea is to not
> allocate objects and prevent allocations altogether.
>
>
Agree (watching capnproto w/ a
On Tue, Feb 2, 2016 at 11:41 AM, Enis Söztutar wrote:
> Google guys over at
> https://github.com/grpc/grpc-java/issues/1054#issuecomment-147295224 are
> saying that CIS changes may be coming to 2.x from what I understand.
I read 'master' as PB3 (Will ask up in issue). We'd run PB3 with the con
My opinion: If this change allows to reduce GC challenges (so more memory
can be allocated to the heap) and increases the performance, this might be
managable...
2016-02-02 14:47 GMT-05:00 Enis Söztutar :
> BTW, we should also be looking at https://google.github.io/flatbuffers/ or
> https://capnp
BTW, we should also be looking at https://google.github.io/flatbuffers/ or
https://capnproto.org/ for serialization as an option. The idea is to not
allocate objects and prevent allocations altogether.
We are allocating PB objects for every Get / Put, then we allocate our Get
/ Put objects. At lea
Google guys over at
https://github.com/grpc/grpc-java/issues/1054#issuecomment-147295224 are
saying that CIS changes may be coming to 2.x from what I understand. If so,
our life would be easier. Even so, I'm 100% sure we have to do shading
since Hadoop will not change it's PB dependency anytime soo
Thanks Duo. If proto3 had what we wanted, you are suggesting we might move
to proto3 setting it to do proto2 support and shade it so we don't clash
with other includes of pb?
Regards Anoop comment, the note on the end of this issue looks promising
but I don't know when it'd see the light of day:
h
UnsafeByteStrings - This may help us to avoid copy even with out our
HBaseZeroCopyByteString stuff. But with a DirectByteBuffer, it has to copy
data to onheap byte[]. We even want a DBB backing !
-Anoop-
On Tue, Feb 2, 2016 at 12:07 PM, 张铎 wrote:
> https://groups.google.com/forum/#!topic/pro
https://groups.google.com/forum/#!topic/protobuf/wAqvtPLBsE8
PB2 and PB3 are wire compatible, and of course, protobuf-java is not
compatible so dependency will be a problem... But I think the shaded client
and server can solve the problem?
Thanks.
2016-02-02 14:27 GMT+08:00 Stack :
> We are run
We are running into a few issues with protobufs.
+ PB always copies all data before making a Message. This generates garbage
unnecessarily.
+ CodedInputStream does not support ByteBuffers in 2.5. In 2.6 it does but
again, copies the data out of the BB always; this is especially painful
when the BB
17 matches
Mail list logo
