Opened 11 years ago

Closed 11 years ago

#14306 closed (fixed)

Translations handling cleanup (with performance boost, too)

Reported by: Anssi Kääriäinen Owned by: Anssi Kääriäinen
Component: Internationalization Version: dev
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


The attached patch implements a different way to handle the delayed translations handling. The idea is to use a class and a getattr based method instead of using the delayed_loader and manipulating the globals.

The only problem with this patch is that if settings.USE_I18N is changed dynamically, the change setting will not change which function (the trans_null or trans_real one) is called. For normal use this is only a good thing (dynamical settings changing is evil), but can cause some problems if testing relies on this. If this is a problem, the class based method can easily be changed to not cache the functions. Just remove the setattr from the getattr method of the TransProvider.

The patch passes all tests.

Attachments (1)

translations_cleanup.diff (5.7 KB) - added by Anssi Kääriäinen 11 years ago.

Download all attachments as: .zip

Change History (3)

Changed 11 years ago by Anssi Kääriäinen

Attachment: translations_cleanup.diff added

comment:1 Changed 11 years ago by Anssi Kääriäinen

Forgot to add info about the performance: I am using the test from #14290, http://localhost:8000/test/10000?timing. Without this patch, I get 16.5 seconds, with this patch, I get 13.5 seconds. There is a total of 60000 calls to get_language. In other words, the performance increase is noticeable only in case get_language gets called in hotspots. This happens to be the case in the ticket #14290, and it will be the case in any code using massive amounts of localization (10x1000 spreadsheet, for example). Also, if you have, say 100, translated strings in your view, this means you will get a free bonus of about 4ms per request (not tested, just calculated) (Or on a real server, probably somewhere in the range of 1ms to 2 ms.

comment:2 Changed 11 years ago by Jannis Leidel

Resolution: fixed
Status: newclosed

(In [13899]) Fixed #14306 -- Cleaned up django.utils.translation module a bit to be quicker. Thanks for the report and initial patch, Anssi Kääriäinen.

Note: See TracTickets for help on using tickets.
Back to Top