开发者

Django internationalization performance issues (3-4s vs 300ms with USE_I18N=False)

So, we have a page with quite a lot of informatio开发者_如何转开发n on in, and we use {% trans %} a lot, but when we actually use them (USE_I18N=True) the site grinds to a halt, ~3.5 seconds with i18n vs 300ms with it off.

We did some profiling and it seems the translation initialization takes forever.

20.2%   0.503 /Library/Python/2.6/site-packages/Django-1.2.1-py2.6.egg/django/utils/translation/__init__.py
15.3%   0.383 /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/genericpath.py
11.4%   0.285 /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/gettext.py
 8.6%   0.215 /Library/Python/2.6/site-packages/Django-1.2.1-py2.6.egg/django/utils/formats.py
 8.5%   0.212 /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/posixpath.py
 8.3%   0.206 /Library/Python/2.6/site-packages/Django-1.2.1-py2.6.egg/django/utils/functional.py
 7.6%   0.189 /Library/Python/2.6/site-packages/Django-1.2.1-py2.6.egg/django/utils/translation/trans_real.py

We tried wrapping the {% trans %} blocks into another templatetag which caches the translations, but that only gained a couple of ms, and the pages are not really that cacheable (except for the translations of course).

Anyone have any experience with this, and/or some pointers on how to make this go faster? Or any pitsfalls we might have gotten ourselfs into?


Seems L10N (new in django 1.2) was the sinner. We solved it by not enabling it (as we use ISO formats everywhere anyways).

Probably should report this to django.. :-)


Bin your custom caches and try some template fragment cacheing - the docs linked show how you can use it with i18n

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜