I was testing performance of the Settings app and decided to check the difference between french locale (l10n-merged) and qps-ploc pseudo locale. Results (master from today, Settings app): | default loc | french | qps-ploc ========================================================== startup | 4705 | 4941 | 5373 mem(app USS) | 13.965 | 14.139 | 17.439 chrome-dom-loaded | 1194 | 1412 | 1921 chrome-interactive | 1195 | 1413 | 1922 startup-path-done | 1807 | 2020 | 2463 app-visually-complete | 2706 | 2938 | 3403 content-interactive | 2707 | 2938 | 3404 app-loaded | 4930 | 5165 | 5587 The non-default locale seem to cost ~200kb which I guess is more related to DOM translation and should get GCed and ~200ms on every step, which I also attribute to DOM translation. Now, pseudolocale seem to cost over 500ms and 3.3mb more. I run this test: MARIONETTE_RUNNER_HOST=marionette-device-host APP=settings RUNS=31 REPORTER=ConsoleMozPerf make test-perf three times and results were within 20-40ms range.

Is that matching what you would expect to see? I'm worried about removing other locales and having only pseudo loc to test non-default characteristic if the pseudo-loc numbers are so different.

The perf slow-down is expected, as we need to run all translation strings through the pseudolocalize function. I'm a bit surprised by the memory footprint, I'll investigate this week, All in all, I'm not too worried. Pseudolocales are not intended to be as fast as regular locales. If one needs to test performance of localization, they should flash a proper multilocale build.

(In reply to Staś Małolepszy :stas from comment #2) > All in all, I'm not too worried. Pseudolocales are not intended to be as > fast as regular locales. If one needs to test performance of localization, > they should flash a proper multilocale build. So, my worry here is that the narrative we give to developers about testing non-default locales is two fold: - whenever you work on UI, enable pseudolocales and switch to them to test your UI - if your work involve performance/boostrap you need to go totally different route. While I understand why it works this way, I don't think it's the best experience for developers to explore. Building a habit of testing against qps-ploc and then building a habit of remembering that it's not a good representation of a perf impact (which translates on UX experience) is confusing. Can we look at trying to minimize the performance difference? One idea, although a bit shady, would be to not reload the default locale resources, but just take them from the locale if the locale is available already. (I stumbled upon it while working on bug 1055328 - pseudo locales will not work there without that) It's not the same optimization (ploc will cost more CPU but less I/O than a normal locale), but maybe it will at least take us closer in the numbers?

We can certainly consider introducing build time optimizations for pseudolocales for developers who which to use them more extensively for testing and dogfooding. For now, if your testing focus is performance of non-English languages, the recommended way to go about it is to flash a proper multilocale build. I edited the MDN page to mention this: https://developer.mozilla.org/en-US/Firefox_OS/Debugging/Developer_settings#Pseudo-localization https://developer.mozilla.org/en-US/Firefox_OS/Debugging/Developer_settings$compare?to=661377&from=658991

Bug 1101632 made it possible to build pseudolocales on buildtime. This is also the default for custom builds. I consider this bug fixed. I edited the MDN docs to reflect the current state of pseudolocales: https://developer.mozilla.org/en-US/Firefox_OS/Debugging/Developer_settings$compare?locale=en-US&to=757435&from=733819