need to test it to
be sure.
This is sort of just a fun experiment for me at this point, so who
knows when I may get around to actually finishing this.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group
it doesn't overallocate quite as
much (in exchange my code does many copies).
Conclusion: there is a legitimate reason for this code to be faster
than the JDK's code. But it still may not be worth including this
patch in the main line protocol buffer code.
Evan
--
Evan Jones
http
On May 3, 2010, at 21:11 , Evan Jones wrote:
Yes, I actually changed ByteString, since ByteString.copyFromUtf8 is
how protocol buffers get UTF-8 encoded strings at this point.
Although now that I think about it, I think it might be possible to
enable this only for SPEED messages
Evan Jones wrote:
Problem 2: Using the NIO encoders/decoders can be faster than
String.getBytes, but only if it is used = 4 times. If used only
once, it is worse. The same is approximately true about decoding.
Lame results: http://evanjones.ca/software/java-string-encoding.html
I'm
buffers and strings. I'll
try to spend some time revisiting this at some point soon.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com
/protorpc/protorpcchannel_test)
==17815==by 0x804A8EF: (within
/home/evanj/hstore/hstore-async/build/protorpc/protorpcchannel_test)
==17815==by 0x80C3C08: __libc_csu_init (in
/home/evanj/hstore/hstore-async/build/protorpc/protorpcchannel_test)
--
Evan Jones
http://evanjones.ca/
--
You
valgrind. I'm assuming that
won't cause any weird failures, but if there might be some problem
that I haven't considered, please let me know.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post
On Mar 22, 2010, at 14:00 , Olan wrote:
const DIDS::Station station_iter = stationlog.station(k);
You probably want stationlog.mutable_station(k);
See:
http://code.google.com/apis/protocolbuffers/docs/reference/cpp-generated.html#fields
Hope this helps,
Evan
--
Evan Jones
http
to figure out where this is happening. My unhelpful guess is that
something is not initialized correctly. Good luck,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email
protocol buffer in the same way, but it seems *possible*?
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send
Kenton Varda wrote:
With Protocol Buffers, we already say that fields can appear in any
order, so any security mechanism built around matching the raw bytes of
a protobuf message against some blacklist is obviously flawed.
Ah, I was not aware of that. Good to know.
Evan
--
Evan Jones
http
of a
mergeDelimitedFrom(CodedInputStream) would be welcomed.
You can do this yourself. I think the following would work:
int length = inputStream.readRawVarint32();
int oldLimit = inputStream.pushLimit(length);
builder.mergeFrom(inputStream);
inputStream.popLimit(oldLimit);
Evan
--
Evan Jones
http
have, but I fear that's
not
going to be very representative as they're mostly simple, flat
messages
where the bulk of the data is inside an opaque bytes field.
If it is representative for *your* application that is probably the
most important part.
Evan
--
Evan Jones
http://evanjones.ca
On Feb 14, 2010, at 17:23 , SyRenity wrote:
Actually, answering myself it seems to be as simple as:
sData.assign(buffer, size); //Where size is the full buffer size
Yes, that works. See the following for more help:
http://www.sgi.com/tech/stl/basic_string.html
Evan
--
Evan Jones
http
, unless I'm thinking about this in the wrong way? I haven't
actually thought about this very hard.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto
want.
See the techniques section on Union Types:
http://code.google.com/apis/protocolbuffers/docs/techniques.html#union
Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post
, std::string assumes buf is a NULL
terminated C string. You should use the following to create the string
with a specific length:
string another_copy(buf, msgStr.size());
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups
/techniques.html#union
If you have many possible types, you may wish to consider implementing
a more complicated protocol where you send a header with the message
type string before the message.
Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because
need to compile without RTTI, simply #define
GOOGLE_PROTOBUF_NO_RTTI.
// On MSVC, this should be detected automatically.
So add -DGOOGLE_PROTOBUF_NO_RTTI and it should work?
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups
buffer messages in both directions. In
fact, if you want to write an RPC implementation, you'll have to do
exactly that: send request messages one way, and reply messages the
other.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google
= protobuffer.name().data()
this gets a pointer to the raw C string inside the C++ string object
inside the protocol buffer object. No allocations or copies will be
performed. Setting the string, one copy is always performed, as Kenton
mentioned.
Evan
--
Evan Jones
http://evanjones.ca/
--
You
?
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more
On Dec 7, 2009, at 0:02 , lexer wrote:
Adam, Could you please show simple example how to use tag number for
dispatch purpose.
I believe he was referring to this sort of thing:
http://code.google.com/apis/protocolbuffers/docs/techniques.html#union
Hope this helps,
Evan
--
Evan Jones
http
for each message.
The reason to use something more complicated is because lots of
applications already have some sort of buffer, and you want to try and
avoid extra copies.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups
at CodedInputStream
C++:
http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.io.coded_stream.html
Java:
http://code.google.com/apis/protocolbuffers/docs/reference/java/index.html?com/google/protobuf/CodedInputStream.html
--
Evan Jones
http://evanjones.ca
/~beechung/ref/gcc-intro.html
Evan
--
Evan Jones
http://evanjones.ca/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe
volunteering to do the work though. :)
Evan
--
Evan Jones
http://evanjones.ca/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
a mapping from message names to Message prototypes, so
you can create a Message of an appropriate type.
Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
, and are of course data dependent.
More benchmarks should be done before making a performance related
code change.
Evan
--
Evan Jones
http://evanjones.ca/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers
in that
context.
Evan
--
Evan Jones
http://evanjones.ca/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from
() or
callback.fail() would probably be clearer and less error prone (eg.
calling setFailed() and forgetting to call callback.run()). I would
definitely accept a breaking API change like this, but I can
understand that others who are using the RPC interface may not agree
with me.
Evan
--
Evan
101 - 131 of 131 matches
Mail list logo
