Standard python 2.6 json is a bundled and cleaned up simplejson without C extension and pre-26 compatibility - even if json serialization is not a common bottleneck why make things worse? Simplejson and python 2.6 json are arguably the same libraries, I think this is like choosing between cStringIO vs StringIO.
суббота, 31 марта 2012 г. 3:03:00 UTC+6 пользователь Alex Ogier написал: > > I did some timing tests. > https://code.djangoproject.com/ticket/18023#comment:5 > > An order of magnitude difference in JSON serialization time corresponds to > an 8% change in total serialization time for a complex model, and 5 deeply > nested model instances can be serialized in < 2 ms. It might be a little > different depending on how deeply your models are related, but it convinced > me that splitting hairs over the JSON serializer isn't worth it. I had the > idea in my head that serialization might be a bottleneck in the same way > that template rendering is, but I realize now it's very different. Heavily > nested and unoptimized templates thrash the disk and change a 10ms response > into a 100ms response. Shoddy JSON serializers might thrash the heap, or > make the GC work overtime, but it's all in memory so the worst that happens > is that a 10ms response becomes a 12ms response. It's just not worth > worrying about. > > Best, > Alex Ogier > > On Fri, Mar 30, 2012 at 2:02 PM, Łukasz Rekucki <[email protected]>wrote: > >> On 30 March 2012 13:04, Alex Ogier <[email protected]> wrote: >> > At the same time, I want to reiterate my support for option #1: not >> deprecating the >> > module and leaving the shim in for the foreseeable future. If >> simplejson is >> > available on the system, and particularly if it has been compiled with C >> > extensions, then there is a significant performance gain to be had, so >> why >> > not continue to take advantage of that in all the places that django >> > serializes to json? >> >> I agree this is a valid concern and I think it should be mentioned in >> release notes. If you want more performance, then option #3 (anyjson) >> would actually be better, but I don't think it should be Django's >> concern to choose the best JSON package for you (we don't do that for >> XML). Instead, imho, Django should provide an ability to pass a custom >> JSON encode/decoder to all APIs that require it, so you can decide >> about it at the project level. >> >> -- >> Łukasz Rekucki >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> >> > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/edityP87yQQJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
