GNOME Bugzilla – Bug 363451
xml2po performance bug
Last modified: 2019-03-25 23:13:08 UTC
xml2po have a performace bug which make . It make any serious use of this tool real PITA (ie. building gnome-user-docs may have 4+hrs. The problem sits in getTranslation() function which constantly recreates gettext.GNUTranslations() and bound file.
Created attachment 75028 [details] [review] Proposed patch
Committed this with a tiny fix (eg. check if mofile is actually defined before trying to initialise gt): thanks for the patch! Test suite showed "only" around 25% improvement (from 7.6s down to 5.6s), which is still a big improvement, but I guess we will get even better improvement for big PO/MO files such as those in gnome-user-docs. So, I really wonder what kind of improvements do you see in building gnome-user-docs with or without this patch?
Also committed to gnome-2-16 branch.
Created attachment 75092 [details] [review] Faster MO reading This is an actually committed version (for reference).
> So, I really wonder what kind of improvements do you see > in building gnome-user-docs with or without this patch? A benchmark on sparc64 that ahze_at_FreeBSD.org (his machine) has tested. Before patch: build started at Wed Oct 18 00:03:31 UTC 2006 build of /usr/ports/misc/gnome-user-docs ended at Wed Oct 18 04:31:42 UTC 2006 After patch: build started at Thu Oct 19 11:36:59 UTC 2006 build of /usr/ports/misc/gnome-user-docs ended at Thu Oct 19 11:58:56 UTC 2006 From almost 4 hours down to 22 minutes. It makes a lot difference on my i386 machine that has FreeBSD 6.1-STABLE too, but I didn't time it.
Wow, cool. I experienced somewhat same results with a single partial translation merge of around 700 messages going down from 67s to 12s. As expected, speedup is linear with MO/PO file sizes, so improvements will be smaller on smaller documents, and better on larger ones. So, all it took was some profiling to see the nasty mistake I did in there. Alexander, thanks a lot, you'll be the hero of many, I promise! :)