On Sep 15, 2011, at 10:49 AM, Ross Peoples wrote: > That is correct. I removed Auth from the model, and just added one dummy > table, and this table definition had the same effect of auth.define_tables(). > Then when I added "migrate=False" to my dummy table, the times for XML > dropped back down to 20 ms. During all of this, the JSON times remained > between 60 ms and 65 ms. > > I will submit a patch to Massimo for the updated files for preferring C json > libraries, using 'json' as the reference instead of simplejson.
I wonder if we should switch to the alternative jsonrpclib as well. It seems like the simplest approach, and it's nice in that it seems to parallel the xmlrpclib logic. I don't like the way the functionality is getting layered. Seems like the proper handling of SSL and persistent connections ought to be independent of the RPC layer; seems dumb to have to re-implement it for both XML-RPC and JSON-RPC. I'm running into the same thing with iOS. There's a good third-party library that handles all the high-level transport stuff--persistent connections, auth, proxies--and it's easy enough to implement JSON-RPC on top of that. But the "standard" third-party XML-RPC library is like the Python one, wrapping the RPC and transport functionality into one piece. Why it's not in the native libraries I have no idea. Anyway, I think it might be a good idea to do some micro-timing. Take a series of timestamps during the request and measure directly where the time is going. As Anthony says, the real mystery is why the JSON timings are so damned stable.
