<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: JSON Performance in Python</title>
	<atom:link href="http://www.mikealrogers.com/archives/695/feed" rel="self" type="application/rss+xml" />
	<link>http://www.mikealrogers.com/archives/695</link>
	<description></description>
	<lastBuildDate>Tue, 02 Mar 2010 07:20:09 -0800</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Comparing Python JSON Implementations &#171; Hustle Play</title>
		<link>http://www.mikealrogers.com/archives/695/comment-page-1#comment-824</link>
		<dc:creator>Comparing Python JSON Implementations &#171; Hustle Play</dc:creator>
		<pubDate>Wed, 23 Dec 2009 12:19:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.mikealrogers.com/?p=695#comment-824</guid>
		<description>[...] JSON Performance in Python [...]</description>
		<content:encoded><![CDATA[<p>[...] JSON Performance in Python [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lloyd Hilaiel</title>
		<link>http://www.mikealrogers.com/archives/695/comment-page-1#comment-707</link>
		<dc:creator>Lloyd Hilaiel</dc:creator>
		<pubDate>Fri, 27 Nov 2009 19:43:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.mikealrogers.com/?p=695#comment-707</guid>
		<description>@mikeal - throw py-yajl in this bucket as well if you like.  @agentdero and I have recently collaborated for speed, and here&#039;s what it currently looks like on my 64bit archlinux box (python 2.6.4) :

ParseTime: cjson 99.72539ms
ParseTime: yajl 141.28672ms
ParseTime: simplejson 223.61533ms
DumpTime: cjson 289.44809ms
DumpTime: yajl 154.87778ms
DumpTime: simplejson 192.81055ms

http://github.com/rtyler/py-yajl

cheers,
lloyd</description>
		<content:encoded><![CDATA[<p>@mikeal &#8211; throw py-yajl in this bucket as well if you like.  @agentdero and I have recently collaborated for speed, and here&#8217;s what it currently looks like on my 64bit archlinux box (python 2.6.4) :</p>
<p>ParseTime: cjson 99.72539ms<br />
ParseTime: yajl 141.28672ms<br />
ParseTime: simplejson 223.61533ms<br />
DumpTime: cjson 289.44809ms<br />
DumpTime: yajl 154.87778ms<br />
DumpTime: simplejson 192.81055ms</p>
<p><a href="http://github.com/rtyler/py-yajl" rel="nofollow">http://github.com/rtyler/py-yajl</a></p>
<p>cheers,<br />
lloyd</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Millikin</title>
		<link>http://www.mikealrogers.com/archives/695/comment-page-1#comment-689</link>
		<dc:creator>John Millikin</dc:creator>
		<pubDate>Mon, 23 Nov 2009 16:49:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.mikealrogers.com/?p=695#comment-689</guid>
		<description>I&#039;m the author of jsonlib (which jsonlib2 forked off of)

First, please don&#039;t use cjson for *anything*. It&#039;s got multiple bugs and misfeatures, and is generally unsuited for anything except impressive benchmarks. It was easier to write my own library, from scratch, than try to fix cjson. To quote somebody, &quot;If I want it done fast and wrong I&#039;ll ask my cat&quot;.

This also means you don&#039;t have to support custom formatters in your libraries, because you don&#039;t need to (and shouldn&#039;t) support cjson.

Second, purely as a matter of curiosity, could you do an equivalent benchmark in Python 3? The version of jsonlib for Python 3 is even faster, because I got to drop some of the performance-degrading compatibility code.</description>
		<content:encoded><![CDATA[<p>I&#8217;m the author of jsonlib (which jsonlib2 forked off of)</p>
<p>First, please don&#8217;t use cjson for *anything*. It&#8217;s got multiple bugs and misfeatures, and is generally unsuited for anything except impressive benchmarks. It was easier to write my own library, from scratch, than try to fix cjson. To quote somebody, &#8220;If I want it done fast and wrong I&#8217;ll ask my cat&#8221;.</p>
<p>This also means you don&#8217;t have to support custom formatters in your libraries, because you don&#8217;t need to (and shouldn&#8217;t) support cjson.</p>
<p>Second, purely as a matter of curiosity, could you do an equivalent benchmark in Python 3? The version of jsonlib for Python 3 is even faster, because I got to drop some of the performance-degrading compatibility code.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michal Chruszcz</title>
		<link>http://www.mikealrogers.com/archives/695/comment-page-1#comment-687</link>
		<dc:creator>Michal Chruszcz</dc:creator>
		<pubDate>Mon, 23 Nov 2009 09:07:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.mikealrogers.com/?p=695#comment-687</guid>
		<description>This might be useful information:
&gt;&gt;&gt; import json
&gt;&gt;&gt; json.__version__
&#039;1.9&#039;
while most important (influencing performance the most) changes in simplejson were added around 2.0 release.

The above chart might suggest that, in situation like yours, i.e. communication with database using JSON, when majority of operations is reading/decoding JSON, the best choice is cjson library. And this is true, with one caveat, though. The latest release of cjson - 1.0.5 - incorporates a bug in decoding escaped double quotes. Although it was never fixed by the maintainer of the library, there are some patches correcting this misbehaviour around, however I don&#039;t know what&#039;s their impact on performance.</description>
		<content:encoded><![CDATA[<p>This might be useful information:<br />
&gt;&gt;&gt; import json<br />
&gt;&gt;&gt; json.__version__<br />
&#8216;1.9&#8242;<br />
while most important (influencing performance the most) changes in simplejson were added around 2.0 release.</p>
<p>The above chart might suggest that, in situation like yours, i.e. communication with database using JSON, when majority of operations is reading/decoding JSON, the best choice is cjson library. And this is true, with one caveat, though. The latest release of cjson &#8211; 1.0.5 &#8211; incorporates a bug in decoding escaped double quotes. Although it was never fixed by the maintainer of the library, there are some patches correcting this misbehaviour around, however I don&#8217;t know what&#8217;s their impact on performance.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mikeal</title>
		<link>http://www.mikealrogers.com/archives/695/comment-page-1#comment-674</link>
		<dc:creator>mikeal</dc:creator>
		<pubDate>Sat, 21 Nov 2009 18:46:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.mikealrogers.com/?p=695#comment-674</guid>
		<description>I&#039;m not a fan of monkey-patching the method names and it doesn&#039;t solve the case where you want to use one module&#039;s decoder and another modules encoder. Ideally, I would want to use cjson&#039;s decoder and simplejson&#039;s encoder so just having a module setting isn&#039;t enough.

I&#039;ve been using that try block since 2.6 was released but now that I&#039;m using couchdb-pythonviews I&#039;m trying to every ms of performance I can out of my json parser.</description>
		<content:encoded><![CDATA[<p>I&#8217;m not a fan of monkey-patching the method names and it doesn&#8217;t solve the case where you want to use one module&#8217;s decoder and another modules encoder. Ideally, I would want to use cjson&#8217;s decoder and simplejson&#8217;s encoder so just having a module setting isn&#8217;t enough.</p>
<p>I&#8217;ve been using that try block since 2.6 was released but now that I&#8217;m using couchdb-pythonviews I&#8217;m trying to every ms of performance I can out of my json parser.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bob Ippolito</title>
		<link>http://www.mikealrogers.com/archives/695/comment-page-1#comment-673</link>
		<dc:creator>Bob Ippolito</dc:creator>
		<pubDate>Sat, 21 Nov 2009 11:02:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.mikealrogers.com/?p=695#comment-673</guid>
		<description>I think the no-monkeys-harmed answer to your question is:

try:
    import simplejson as json
except ImportError:
    import json</description>
		<content:encoded><![CDATA[<p>I think the no-monkeys-harmed answer to your question is:</p>
<p>try:<br />
    import simplejson as json<br />
except ImportError:<br />
    import json</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Leechael</title>
		<link>http://www.mikealrogers.com/archives/695/comment-page-1#comment-671</link>
		<dc:creator>Leechael</dc:creator>
		<pubDate>Sat, 21 Nov 2009 06:21:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.mikealrogers.com/?p=695#comment-671</guid>
		<description>I&#039;m have doubt why not you don&#039;t use timeit module for benchmarking....</description>
		<content:encoded><![CDATA[<p>I&#8217;m have doubt why not you don&#8217;t use timeit module for benchmarking&#8230;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: matt harrison</title>
		<link>http://www.mikealrogers.com/archives/695/comment-page-1#comment-670</link>
		<dc:creator>matt harrison</dc:creator>
		<pubDate>Sat, 21 Nov 2009 05:04:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.mikealrogers.com/?p=695#comment-670</guid>
		<description>Maybe I&#039;m not reading that last paragraph right, but couldn&#039;t you either do some monkey patching to the module json and force its dump/load to actually use the fast code?   Or create a json library that is just a wrapper that can do the try/except import dance for the fast apis and wrap those accordingly?</description>
		<content:encoded><![CDATA[<p>Maybe I&#8217;m not reading that last paragraph right, but couldn&#8217;t you either do some monkey patching to the module json and force its dump/load to actually use the fast code?   Or create a json library that is just a wrapper that can do the try/except import dance for the fast apis and wrap those accordingly?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Python 的 JSON library 速度比較 at Gea-Suan Lin&#8217;s BLOG</title>
		<link>http://www.mikealrogers.com/archives/695/comment-page-1#comment-669</link>
		<dc:creator>Python 的 JSON library 速度比較 at Gea-Suan Lin&#8217;s BLOG</dc:creator>
		<pubDate>Sat, 21 Nov 2009 03:22:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.mikealrogers.com/?p=695#comment-669</guid>
		<description>[...] 在「JSON Performance in Python」這篇看到比較圖，在 Python 2.6 上面測試 json (stdlib)、simplejson、jsonlib2、cjson 這四個不同的 JSON library 的速度。 [...]</description>
		<content:encoded><![CDATA[<p>[...] 在「JSON Performance in Python」這篇看到比較圖，在 Python 2.6 上面測試 json (stdlib)、simplejson、jsonlib2、cjson 這四個不同的 JSON library 的速度。 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bob Ippolito</title>
		<link>http://www.mikealrogers.com/archives/695/comment-page-1#comment-666</link>
		<dc:creator>Bob Ippolito</dc:creator>
		<pubDate>Sat, 21 Nov 2009 00:35:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.mikealrogers.com/?p=695#comment-666</guid>
		<description>The stdlib json is so far behind because they wouldn&#039;t take the patch with all of the C speedups because it was too close to the release deadline. I also couldn&#039;t get it in a point release since too much code changed and some behavior did too. There&#039;s probably still something sitting in the tracker so hopefully it will make it in 2.7.</description>
		<content:encoded><![CDATA[<p>The stdlib json is so far behind because they wouldn&#8217;t take the patch with all of the C speedups because it was too close to the release deadline. I also couldn&#8217;t get it in a point release since too much code changed and some behavior did too. There&#8217;s probably still something sitting in the tracker so hopefully it will make it in 2.7.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
