On Mar 16, 9:59 pm, Caleb wrote:
> Here are the results of a reasonably faithful port of Jon's Java
> benchmark code to C++. I'll see if I can post the code to the "Files"
> section of the Google Group.
Well, I can't do that, but this is probably better:
http://github.com/Bklyn/protobuf/tree/
On Mar 5, 7:07 am, Jon Skeet wrote:
> This is only an initial cut, but I wanted to get it out into the
> community quickly rather than polishing build scripts etc. You
> currently have to build by hand, but there are instructions in the
> readme.
Here are the results of a reasonably faithful po
On Mar 11, 9:42 am, "Jon Skeet "
wrote:
> There's still an optimisation I want to make in terms of unknown field
> sets, which made a difference to the C# code, but this result is
> really amazing...
Indeed, the Server JIT has a much wider set of optimisations at its
disposal. The Client JIT ass
On Mar 5, 11:49 am, "Jon Skeet "
wrote:
> > Before any other settings are tried, it would be worth benchmarking it
> > with -server as it can make a large difference when compared to -
> > client. The default varies based on OS and machine specification so it
> > makes sense to use an explicit se
On Fri, Mar 6, 2009 at 5:28 AM, Jon Skeet wrote:
>
> On Mar 6, 1:24 pm, Justin Azoff wrote:
> > On Mar 6, 1:13 am, Justin Azoff wrote:> I did
> a quick port to python(pasted at the end, hopefully it wont be
> > > garbled)
> >
> > well, that didn't work.
> > I threw it up athttp://bouncybounc
On Mar 6, 1:24 pm, Justin Azoff wrote:
> On Mar 6, 1:13 am, Justin Azoff wrote:> I did a
> quick port to python(pasted at the end, hopefully it wont be
> > garbled)
>
> well, that didn't work.
> I threw it up athttp://bouncybouncy.net/ramblings/files/ProtoBench.py
> if anyone is interested.
On Mar 6, 1:13 am, Justin Azoff wrote:
> I did a quick port to python(pasted at the end, hopefully it wont be
> garbled)
well, that didn't work.
I threw it up at http://bouncybouncy.net/ramblings/files/ProtoBench.py
if anyone is interested.
--
- Justin
--~--~-~--~~~-
On Mar 6, 3:27 am, lahike...@gmail.com wrote:
> 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 cate
On Mar 5, 6:07 am, Jon Skeet 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 on a 3.2gh
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 da
On Mar 5, 11:47 am, ijuma 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 running the Jav
Hi Jon,
On Mar 5, 11:07 am, Jon Skeet 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 running th
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 init
13 matches
Mail list logo
