On Tue, Nov 9, 2010 at 6:21 AM, Kalki70 <kalki...@gmail.com> wrote:

> On Nov 9, 10:13 am, multijon <multi...@gmail.com> wrote:
> > As a side note, the company I worked at used ASN.1 for five years to
> > encode all of its product's communication messages (Using PER
> > encoding), with what was supposed to be a highly optimized
> > implementation of ASN.1.
> >
> > One of my last projects in the company was to try and convert our
> > encoding method (and the underlying data structure) from ASN.1 to
> > Protobuf. A project that was estimated to be long and tiring turned
> > out to be rather easy, eliminating plenty of unnecessary (in protobuf,
> > but necessary in ASN.1) memory allocations, thus both speeding
> > performance and decreasing the memory footprint of our product by
> > 50-70% (!).
> Again I must insist about this. ASN.1 doesn't use memory allocations.

Yes, but the implementations do. Try getting an ASN.1 implementation as
efficient as protocol buffers. It takes a lot more effort than implementing
protocol buffers from scratch. That's part of the advantage.

> There are some very good, like from OSS Novalka.

First, they provide about a dozen different products for ASN.1, which by
itself saying a lot about ASN.1's complexity. Secondly, the tool isn't
available as open source. Additionally, the solution is so "cheap" that they
don't list pricing (I'm trying to remember the pricing the last time I
looked at it, but it escapes me). Finally, the last time I tested it, the
encode/decode wasn't nearly as fast in C++, let alone Java. There isn't even
an implementation for Python or a variety of other languages that have very
fast and fully compatible implementations of protocol buffers. Those are
some huge advantages for protocol buffers in my mind, despite OSS having
devoted far more resources to tackling the problem than everyone
collectively has on protocol buffers.


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 
For more options, visit this group at 

Reply via email to