Re: Speed comparison between vanilla pyyaml and pyyaml+libyaml

Jesse Noller <[email protected]>
Newsgroups gmane.text.yaml.general
Message-ID <[email protected]>
On Tue, Apr 21, 2009 at 9:52 PM,  <[email protected]> wrote:
> I ran across the following posts a little while ago:
>
> I'm a heavy yaml consumer, so I thought I'd experiment with vanilla YAML
> speed runs of the same benchmark, and then with pyyaml+libyaml, with cython
> installed. What bothers me is that there's a negligible difference in speed,
> even with libyaml installed, and pyyaml using the cyaml extension:
>
> Here's the relevant numbers:
>
> Vanilla PyYAML:
>
> ser_yaml (6.320s) 623436 bytes
> ser_yaml_compressed (6.410s) 291050 bytes
> serde_yaml (18.550s)
>
> PyYAML + libyaml:
>
> ser_yaml (6.150s) 623488 bytes
> ser_yaml_compressed (6.240s) 291175 bytes
> serde_yaml (18.950s)
>
> On the serde_yaml test, I've consistently gotten worse speeds than plain old
> pyyaml. I'm wondering if you guys have any thoughts/ideas on this. I've
> posted the modified benchmark code to:
>
> http://jessenoller.com/code/test_yaml.py
>
> FWIW, this is on a dual core OS/X box. In the morning, I'll try running it
> on an available Linux machine just for sanity's sake
>
> jesse

Mea culpa, it's later here, and I forgot to include the links I meant
to reference:

http://www.bouncybouncy.net/ramblings/posts/thrift_and_protocol_buffers/
http://www.bouncybouncy.net/ramblings/posts/more_on_json_vs_thrift_and_protocol_buffers/
http://www.bouncybouncy.net/ramblings/posts/json_vs_thrift_and_protocol_buffers_round_2/

-jesse

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.