I've just committed the first pass of a benchmarking tool to trunk.
Everything is under benchmarks - see the readme.txt for usage
guidelines.
I have a bit of tidying up to do before the committed C# version is
*exactly* equivalent (I've changed my build file around a bit) but
I've got some
Hi Jon,
On Mar 5, 11:07 am, Jon Skeet sk...@pobox.com wrote:
I haven't optimised with a profiler very recently - I suspect there
are some improvements which could be made by skipping the null
handling when merging/parsing (as it should be unnecessary). I didn't
use any particular options
On Mar 5, 11:47 am, ijuma isma...@gmail.com wrote:
I haven't optimised with a profiler very recently - I suspect there
are some improvements which could be made by skipping the null
handling when merging/parsing (as it should be unnecessary). I didn't
use any particular options when
On 04.03.2009 20:22, lahike...@gmail.com wrote:
Well, it seems like all your technical problems will be solved by my
configure check -- which will nicely tell the user that the need to
install protobuf or modify their CFLAGS/LDFLAGS.
Why make user do that manually if there is a much more
I have a fairly old version of the protobuf library, so if this has
been changed let me know, but I have a situation where Message::Clear
() is causing my cpu to go to like 70% for an extended period of time.
It's also possible this is user error, so please correct me if that's
the case.
Wow, that's interesting. I don't know why it would do that. Can you look
deeper into your profiles and see what part of Clear() is taking so long?
For example, is it spending the time clearing STL strings?
On Thu, Mar 5, 2009 at 3:11 PM, Zachary Turner divisorthe...@gmail.comwrote:
I have a
I'll give it a try. I haven't built the protobuf libraries with
instrumenting support or else I'd already know, but I should be able
to get it working.
On Mar 5, 5:20 pm, Kenton Varda ken...@google.com wrote:
Wow, that's interesting. I don't know why it would do that. Can you look
deeper
Hi all,
As you know if you've read the docs carefully, when using C++ or Java
protocol buffers, for best performance you need to add a line to your .proto
files:
option optimize_for = SPEED;
Otherwise, by default, the compiler optimizes for code size. Optimizing for
code size results in
I get somewhat better results with that flag. I built protobuf with
profiling enabled and I'm a little suspicious that the information is 100%
accurate, but it seems like std::string::clear() takes up the most time.
But the percentages don't match up to what I calculate, so I'm not sure
where
On Thu, Mar 5, 2009 at 4:02 PM, Zachary Turner divisorthe...@gmail.comwrote:
I get somewhat better results with that flag. I built protobuf with
profiling enabled and I'm a little suspicious that the information is 100%
accurate, but it seems like std::string::clear() takes up the most time.
On Mar 4, 10:24 pm, David Anderson d...@natulte.net wrote:
I think the major point to take away from the comparison is: use the
correct tool for your needs. If you need backward/forward
compatibility, heterogeneous versions of software interacting and some
structural validation (just
I appreciate this, as i've been wanting to see some benchmarks between
the implementations for a long time. Of course, as a C advocate (i'm
the author of protobuf-c), I'm hoping (and frankly expecting) that
it'll win in the size AND speed category.
I also like the style of separating the test
On Mar 5, 6:07 am, Jon Skeet sk...@pobox.com wrote:
I've just committed the first pass of a benchmarking tool to trunk.
Everything is under benchmarks - see the readme.txt for usage
guidelines.
Cool :-)
I did a quick port to python(pasted at the end, hopefully it wont be
garbled), my results
+1 for SPEED.
-dave
On Mar 5, 3:39 pm, Kenton Varda ken...@google.com wrote:
Hi all,
As you know if you've read the docs carefully, when using C++ or Java
protocol buffers, for best performance you need to add a line to your .proto
files:
option optimize_for = SPEED;
Otherwise, by
14 matches
Mail list logo
