On Mon, Mar 2, 2009 at 3:43 AM, Jon Skeet wrote:
> I've ported the code to Java, but haven't sent it to Kenton yet. I don't
> know exactly where we'd want to put it in the main distribution. Kenton, how
> do you want to proceed with this?
>
A top-level "benchmark" directory seems like it would m
I'm interested in your work, Josh. But I'm having trouble
understanding what your goal is. I.e. what is the essence of protobufs
that you are trying to distill? And how would you differentiate your
work from Dave's protobuf-c project? And is your implementation going
to be entirely in C?
Tim
On
2009/3/2 Kenton Varda
> It would be nice if there was an open-source benchmark suite that would
>> make it easier to compare performance across implementations.
>>
>
> I believe Jon Skeet was working on that. Jon, any progress?
>
The relevant data is all available under
http://github.com/jskee
On Sun, Mar 1, 2009 at 6:56 PM, Kenton Varda wrote:
> I believe GCC's std::string will only malloc if it needs to grow, so on
> reuse there should be no new allocation.
>
I meant, reuse to store a string of the same or lesser size, of course.
--~--~-~--~~~---~--~
On Sun, Mar 1, 2009 at 3:42 PM, Joshua Haberman wrote:
> What about strings and repeated elements? String assignment will at least
> sometimes call malloc() to re-allocate the string, though I don't know
> enough about STL to know how often this happens. And string assignment will
> always copy
On Sun, Mar 1, 2009 at 3:24 PM, Kenton Varda wrote:
> On Sun, Mar 1, 2009 at 2:12 PM, Joshua Haberman wrote:
>
>>
>> Stripping down protobufs to their essence is *exactly* what I am doing
>> with pbstream:
>>
>> http://github.com/haberman/pbstream
>>
>> If you can hang tight for just another few
On Sun, Mar 1, 2009 at 2:12 PM, Joshua Haberman wrote:
>
> Stripping down protobufs to their essence is *exactly* what I am doing
> with pbstream:
>
> http://github.com/haberman/pbstream
>
> If you can hang tight for just another few weeks, I think you're going
> to like what you see. The stream
Stripping down protobufs to their essence is *exactly* what I am doing
with pbstream:
http://github.com/haberman/pbstream
If you can hang tight for just another few weeks, I think you're going
to like what you see. The streaming decoder is more or less finished:
it's just over 500 lines of C99
That sounds like an excellent idea!
On Feb 27, 11:51 am, Kenton Varda wrote:
> Stripping out the use of file descriptors and iostreams should be easy. All
> you have to do is remove the relevant classes from
> zero_copy_stream_impl.{h,cc} and the corresponding methods from
> message.{h,cc}. Th
Stripping out the use of file descriptors and iostreams should be easy. All
you have to do is remove the relevant classes from
zero_copy_stream_impl.{h,cc} and the corresponding methods from
message.{h,cc}. The rest of the library doesn't depend on these. Note that
protoc needs them, but presuma
That's precisely the case I've been hoping to make in my current work.
Since it's a static library to us, the point of stripping down isn't
so much for reduced footprint (our linker should eliminate the unused
modules anyway), but instead to simplify the porting effort.
One of the first things I
I've tested in on OSX, FreeBSD, and Solaris, but those are not terribly
different from Linux. The Google implementations of protobufs definitely
weren't designed for embedded systems, but there might be a case for taking
the Google C++ implementation and ripping out all the "advanced" features to
12 matches
Mail list logo
