utilities always open and parse translation files, even when they're not needed

[andreacorbellini]

When tracing (via strace) the uutils coreutils, I've noticed that they always open and fully read the translation files, for example:

$ strace -e trace=open,openat,read -- target/debug/cat /dev/null
...
openat(AT_FDCWD, "/home/andrea/src/coreutils/src/uucore/locales/en-US.ftl", O_RDONLY|O_CLOEXEC) = 3
read(3, "# Common strings shared across a"..., 2553) = 2553
read(3, "", 32)                         = 0
openat(AT_FDCWD, "/home/andrea/src/coreutils/src/uucore/../uu/cat/locales/en-US.ftl", O_RDONLY|O_CLOEXEC) = 3
read(3, "cat-about = Concatenate FILE(s),"..., 965) = 965
read(3, "", 32)                         = 0
openat(AT_FDCWD, "/home/andrea/src/coreutils/src/uucore/locales/en-US.ftl", O_RDONLY|O_CLOEXEC) = 3
read(3, "# Common strings shared across a"..., 2553) = 2553
read(3, "", 32)                         = 0
openat(AT_FDCWD, "/home/andrea/src/coreutils/src/uucore/../uu/cat/locales/en-US.ftl", O_RDONLY|O_CLOEXEC) = 3
read(3, "cat-about = Concatenate FILE(s),"..., 965) = 965
read(3, "", 32)                         = 0
openat(AT_FDCWD, "/dev/null", O_RDONLY|O_CLOEXEC) = 3
read(3, "", 65536)                      = 0
+++ exited with 0 +++

In release mode, it seems like the tools can't generate the correct path (this happens both when building using cargo run --release from a fresh checkout, and also with the version of coreutils shipped with Ubuntu 25.10), but that's a separate problem from the one in this bug report:

$ strace -e trace=open,openat,read -- target/release/cat /dev/null
...
openat(AT_FDCWD, "/home/andrea/src/coreutils/target/release/cat/en-US.ftl", O_RDONLY|O_CLOEXEC) = -1 ENOTDIR (Not a directory)
openat(AT_FDCWD, "/home/andrea/src/coreutils/target/release/cat/en-US.ftl", O_RDONLY|O_CLOEXEC) = -1 ENOTDIR (Not a directory)
openat(AT_FDCWD, "/dev/null", O_RDONLY|O_CLOEXEC) = 3
read(3, "", 65536)                      = 0
+++ exited with 0 +++

In the majority of the cases however, the utilities don't need any of these messages: most utilities in fact won't ever print a message when used correctly. Utilities only print messages when (1) the user specifies --help or similar, or (2) an error has occurred. For most scripts, these two scenarios are relatively rare. I believe that implementing a "lazy loading" strategy for translation would give a significant performance boost for all utilities.

[andreacorbellini]

I would like to submit a PR for addressing this myself, but I have a question: I see that the Localizer is used in a thread-local context, and by reading tests it seems like, by design, each thread is supposed to do its own locale initialization, and threads are allowed to each use a different locale.

If I had to change the locale code to use lazy initialization, the easiest thing that comes to my mind is to just use a single, global (not thread-local) Localizer object that is initialized to the locale specified in the environment. This of course would rule out the possibility of having threads with different locales.

I can still implement a lazy-initialization strategy with thread-specific locales, but I would like to understand more about the need for that: what utilities need to use different locales in different threads, and why?

[andreacorbellini]

I tried to experiment with lazy loading of translations, but then realized that translated strings are looked up at the beginning of every program in order to initialize clap. Proposed this feature request to the clap project: clap-rs/clap#6171 to make it easier for coreutils to implement lazy loading.

[sylvestre]

Yes, we should fix that. With commands that do just a little bit of heavy work (cp, ls, sort, etc) , it is insignificant but for some, it can represent a significant % of the work.