It would appear to be just the C implementation. Regular pickle takes approximately the same amount of time as JSON.  The integer key issue is a serious one.<div><br></div><div>Any JSON serialized dict with integer keys will get reconstructed incorrectly with string keys. Approximately 100% of controller messages include such a thing (keyed by engine IDs). I can get around it easily enough in the controller/client code (in ugly ways), but it&#39;s user code that I&#39;m worried about. It means that we cannot, in general, allow user dicts to be sent if we use JSON, unless on every send we walk all iterables and convert every dict we find to a custom dict subclass, which is certainly unacceptable.<div>

<br></div><div>This is not a problem with Python&#39;s JSON, it&#39;s a problem with JSON itself.</div><div><br><div class="gmail_quote">On Thu, Jul 22, 2010 at 13:31, Fernando Perez <span dir="ltr">&lt;<a href="http://fperez.net">fperez.net</a>@<a href="http://gmail.com">gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hey Min,<br>
<div class="im"><br>
On Thu, Jul 22, 2010 at 2:22 AM, MinRK &lt;<a href="mailto:benjaminrk@gmail.com">benjaminrk@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; It would appear that json is contributing 50% to the overall run time.<br>
<br>
</div>any chance you could re-test using pickle instead of cPickle?  I want<br>
to see if the difference vs json is just from the faster C<br>
implementationo of cPickle.  If that&#39;s the case, we could later<br>
consider implementing a cython-based version of the json dump/load<br>
code.<br>
<br>
Cheers,<br>
<font color="#888888"><br>
f<br>
</font></blockquote></div><br></div></div>