On Tue, 2011-08-30 at 14:17 +0200, Gregory Collins wrote:
Dumb question: are the values you're encoding forced before you call the JSON serialization function? If you have unevaluated thunks in there, it could cause the profiler to misattribute the time to aeson.
They are not... but it turns out the profiling was accurate. I talked to Bryan about this, and he did some checking around, and basically concluded that there is no way to do the JSON serialization with acceptable performance, even by dropping down to an optimized implementation in C. It's a combination, I think, between the size of the messages and the fact that so much of their contents are floating point numbers. I rewrote this bit of code last night to send (base64-encoded) binary data instead, and the results are dramatic: streaming an animation that was choppy and used 100% CPU on the server before is now smooth and uses about 6% CPU time. It's a good bit easier on the client as well: Chromium goes from itself spinning at 100% CPU to using around 25% to display the animation. I guess the lesson here is that JSON encoding (and parsing) carries some very substantial overhead in many cases. It's better than XML, but no substitute for a binary format. -- Chris