I'm a bit confused about how constructing a builder could be as slow as you
describe it.  It's just an object allocation.  Granted, two objects need to
be allocated instead of just one, due to the builder design, but object
allocations aren't very expensive.  Can you provide more detail on what you
found slow?  A realistic benchmark demonstrating the problem would be ideal.

The independent benchmarks done by the thrift-protobuf-compare project show
that yes, protobuf object creation is slower than others, but the difference
is so small compared to parsing and serialization time that protobuf ends up
near the front of the pack in "total time":

http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

On Sun, Apr 11, 2010 at 4:57 PM, David Hart <dh...@opencog.org> wrote:

> Hi All,
>
> Please cross-post all (any) followups to this thread. Now, please see this:
>
> On 12/04/2010, at 8:19, Drew Botwinick <drew.botwin...@gmail.com> wrote:
>
>  I'm gonna go a bit off-topic and I apologize in advance for doing
>> that. Protocol Buffers are probably not the best match here as Boris
>> has already identified. I figured I'd share my other experience/
>> concerns with java protobuf here as a sidenote.
>>
>> Google Protocol Buffers are actually a bit disappointing in Java. I've
>> run some tests with protobuf and found that although the performance
>> was great in most respects... the amount of time it takes to generate
>> a message using the "Message.Builder" is painfully slow. It takes way
>> too long to instantiate a Message.Builder and there is no point in
>> profiling the issue away because as soon as u make any changes to
>> your .proto files... you'll compile that into java classes and undo
>> your optimizations. I could only come up with 3 ways to fix protobuf:
>>
>> 1) find the source of the issue once and for all and commit the fixes
>> to the protobuf project so that from now on... all java generated
>> source is improved [which is not exactly trivial... I didn't spend
>> very long looking for the issue, but it certainly wasn't obvious]
>> 2) try to arrange message builders into some kind of work queue so
>> that you can re-use them (which violates their designed functionality
>> and leads to all sorts of ugliness)
>> 3) use python or c instead of java since the issues are java specific.
>>
>> I think protobuf is great... especially since it's well supported,
>> well designed, and bindings are available for many languages and
>> platforms, but it has some quirky java performance issues that don't
>> make it the best choice (in java) if performance is your number one
>> concern. If you're willing to sacrifice a few dozen milliseconds here
>> and there, it's a great solution for an extensible cross-platform
>> messaging format.
>>
>> -Drew
>>
>> On Apr 11, 5:51 am, David Hart <dh...@opencog.org> wrote:
>>
>>> Can Google's 'Protocol Buffers', while written in C, be of any
>>> guidance, inspiration or use? Presumably, Google (or someone else)
>>> have written Java wrappers for PB?
>>>
>>> -Dave
>>>
>>> David Hart | phone +61 419 483 263 | sent from iPhone
>>>
>>> On 11/04/2010, at 8:51, Drew Botwinick <drew.botwin...@gmail.com> wrote:
>>>
>>>
>>>
>>>  Hi all,
>>>>
>>>
>>>  I'm new to the project and I'm looking to implement a bunch of new
>>>> features as well as fix existing issues.
>>>>
>>>
>>>  I have an idea for an approach (but not a complete solution) to
>>>> resolving issue #21 which is that ObjectInputStream and
>>>> ObjectOutputStream cannot be configured to use a different class
>>>> loader than the original class loader of HGDB. My proposed solution is
>>>> to use "serialization containers". It's a bit of a "hack" solution and
>>>> is sort of half way between providing custom serialization and using
>>>> java serialization (because it can do both). I'll explain in more
>>>> detail below.
>>>>
>>>
>>>  The idea is simple. The SerializableType should force the inclusion of
>>>> a writeReplace() method. The writeReplace method should replace the
>>>> type to be serialized with a "serialization container" with an
>>>> interface such as:
>>>>
>>>
>>>  public interface SerializedDataContainer<T> extends Externalizable {
>>>>   public Object readResolve() throws ObjectStreamException;
>>>>
>>>
>>>    public void writeExternal(ObjectOutput out) throws IOException;
>>>>
>>>
>>>    public void readExternal(ObjectInput in) throws IOException,
>>>> ClassNotFoundException;
>>>> }
>>>>
>>>
>>>  The reason for choosing Externalizable is so that the container can
>>>> dictate either using the standard java serialization or any custom
>>>> serialization. readResolve() should construct the object using
>>>> whatever class loader is appropriate.  The downside of this option is
>>>> that by the time you implement the container scheme... you might as
>>>> well be providing a method of serialization other than vanilla java
>>>> serialization anyway. I've used the above container scheme
>>>> successfully elsewhere, but I originally used this approach so that I
>>>> could easily substitute alternate serialization mechanisms into code
>>>> originally designed to be used with java serialization. (My data
>>>> container had 1 private field that was a byte[]).
>>>>
>>>
>>>  As I see it, it's very difficult to manipulate the vanilla java
>>>> serialization scheme to use alternate class loaders, and this,
>>>> although it's a roundabout solution, does provide a method of choosing
>>>> your class loader by some other means; however, it'd be hard to
>>>> generalize... it'd be very application specific...and at worst... very
>>>> type specific (which at that point... why not just have an alternate
>>>> serialization mechanism anyway?)
>>>>
>>>
>>>  Thoughts? Comments? Concerns? Any feedback is appreciated. :-)
>>>>
>>>
>>>  --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "HyperGraphDB" group.
>>>> To post to this group, send email to hypergrap...@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> hypergraphdb+unsubscr...@googlegroups.com<hypergraphdb%2bunsubscr...@googlegroups.com>
>>>> .
>>>> For more options, visit this group athttp://
>>>> groups.google.com/group/hypergraphdb?hl=en
>>>> .
>>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "HyperGraphDB" group.
>> To post to this group, send email to hypergrap...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> hypergraphdb+unsubscr...@googlegroups.com<hypergraphdb%2bunsubscr...@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/hypergraphdb?hl=en.
>>
>>
> --
> 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<protobuf%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/protobuf?hl=en.
>
>

-- 
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 options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Reply via email to