ok, I took I/O out of the picture by serializing each message into a
pre-allocated buffer, and this time I did a more through measurement.
Benchmark 1: Complete scenario
- average time 262ms (100 runs)
Benchmark 2: Same as # 1 but no IO
- average time 250ms (100 runs)
Benchmark 3: Same as 2
Kenton: I made a mistake with these numbers - pls ignore them - I'll revisit
tomorrow.
Thx.
-Original Message-
From: protobuf@googlegroups.com [mailto:proto...@googlegroups.com] On Behalf Of
Alex Black
Sent: Tuesday, July 14, 2009 2:05 AM
To: Protocol Buffers
Subject: Re: Performance:
OK. If your message composition (or parsing, on the receiving end) takes a
lot of time, you might look into how much of that is due to memory
allocation. Usually this is a pretty significant fraction. Two good ways
to improve that:
1) If your app builds many messages over time and most of them
Thanks a lot!
On Jul 14, 1:18 am, Kenton Varda ken...@google.com wrote:
I've pretty much finished the refactoring. Ideally I'd like to get it into
SVN this week, but realistically it will probably happen next week or the
week after since I will be out of town from the 16th to the 22nd. An
Thanks for those tips. I am using tcmalloc, and I'm re-using message
for each batch, e.g. I fill it up with say 500 items, send it out, clear
it, re-use it.
Here are my hopefully accurate timings, each done 100 times, averaged:
1. Baseline (just loops through the data on the server) no
I am getting the error
com.google.protobuf.Descriptors.FileDescriptor.InternalDescriptorAssigner
cannot be resolved to a type
when Eclipse compiles my generated Java code? I wrote a plugin that
generates the protocol buffer messages from the ecore file of an EMF
Model diagram. It creates a new
DIGITAL PRINTING VS THE TRADITIONAL MET...DIGITAL PRINTING VS THE
TRADITIONAL MET...DIGITAL PRINTING VS THE TRADITIONAL MET...
http://attraction123.50webs.com/Digital_Printing_vs_the_Traditional_met.html
http://attraction123.50webs.com/Digital_Printing_vs_the_Traditional_met.html
It looks like your protobuf library and protocol compiler binary are from
different releases. This won't work. Please make sure both are upgraded to
2.1.0, the latest release.
On Tue, Jul 14, 2009 at 8:52 AM, Michael Stapleton
mike.staple...@echostar.com wrote:
Hi All,
I am using release
Answered in the other thread -- you need to use matching protoc and protobuf
library versions.
On Tue, Jul 14, 2009 at 2:57 PM, Mike mike.staple...@echostar.com wrote:
I am getting the error
com.google.protobuf.Descriptors.FileDescriptor.InternalDescriptorAssigner
cannot be resolved to a
Kenton Monty,
I added hack as followes in the hash.h
// File changed .
#if defined(HAVE_HASH_MAP) defined(HAVE_HASH_SET)
#include HASH_MAP_H
#include HASH_SET_H
#elif defined (__xlC__)
#define MISSING_HASH
#include unordered_map
#include unordered_set
#else
#define MISSING_HASH
It looks like your implementation of hash_map is not working correctly --
all lookups are failing. You might try writing a little test for hash_map
itself that would be easier to debug.
On Tue, Jul 14, 2009 at 6:27 PM, vikram patilvik...@gmail.com wrote:
Kenton Monty,
I added hack
11 matches
Mail list logo
