We recently migrated our app to gt-react (11.1.6) with 55 locales in our gt.config.json, and noticed that re-renders were roughly 2x slower than before the migration. After profiling, most of the overhead was coming from the locale utilities rather than anything in our own code.
The cause seems to be that LocaleConfig.determineLocale() and requiresTranslation() re-validate the entire locale list on every call, and both of them run per hook per render through useLocale/useGT. With a big locale list that adds up fast:
const { LocaleConfig } = require('@generaltranslation/format');
const locales = ["es","zh","zh-Hant","hi","bn","ar","pt-BR","fr","de","it","ru","pt-PT","ja","ko","vi","th","id","ms","fil","ur","ta","ml","gu","fa","tr","kk","mn","hy","ka","uk","pl","cs","sk","sr","hr","sl","mk","bg","lt","et","lv","sv","no","da","fi","is", "nl","el","hu","ro","sq","ca","cy","af"];
const config = new LocaleConfig({ defaultLocale: 'en', locales });
console.time('x1000');
for (let i = 0; i < 1000; i++) config.requiresTranslation('ar');
console.timeEnd('x1000'); // ~150msSince the config fields these read from are only set in the constructor, we memoized these methods in a local patch as a workaround. The outputs are unchanged and the same 1000-call loop drops to ~9ms.
We recently migrated our app to gt-react (11.1.6) with 55 locales in our gt.config.json, and noticed that re-renders were roughly 2x slower than before the migration. After profiling, most of the overhead was coming from the locale utilities rather than anything in our own code.
The cause seems to be that
LocaleConfig.determineLocale()andrequiresTranslation()re-validate the entire locale list on every call, and both of them run per hook per render throughuseLocale/useGT. With a big locale list that adds up fast:Since the config fields these read from are only set in the constructor, we memoized these methods in a local patch as a workaround. The outputs are unchanged and the same 1000-call loop drops to ~9ms.