GNOME Bugzilla – Bug 368001
dlopening ~120 files in /usr/lib/gconv/
Last modified: 2018-02-28 17:00:24 UTC
This is for a vanilla SuSE 10.1 install, if that matters. Starting up the first gnome-terminal takes entirely too long, so I did a strace and started looking. Font-config is doing loads of stupid things, but it does so for other gnome applications too, so I won't blame gnome-terminal for that. However. one thing that gnome-terminal does and that, say, Gnumeric does not is something locale related: > grep gconv ~/ttt | head open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 3 <0.000017> open("/usr/lib/gconv/ISO8859-1.so", O_RDONLY) = 4 <0.000030> open("/usr/lib/gconv/ISO8859-2.so", O_RDONLY) = 16 <0.017475> open("/usr/lib/gconv/ISO8859-3.so", O_RDONLY) = 16 <0.000076> ... And it in facts mmaps these, so they are likely the result of dlopens. There are ~120 of these, so this adds up. I am not doing anything fancy locale-wise: > locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=
The terminal does, at start up time, a test to see if the conversions it knows about work cleanly in the system it is running in. While not all of these tests can be deferred (a couple are needed to see if things are going to work at all), one could try to see if deferring most of those tests to when the Terminal->Character Encoding->Add or Remove... dialog gets run. This might end up in an unbearable lag when showing that dialog. Most of this happens (quite previsibly ;-) in src/encodings.c.
You could use an idle handler, then. Every time it triggers it could handle a single encoding. Unless someone went directly to Terminal->Character Encoding->Add or Remove... that should handle everything in the background.
Or a simple progress bar dialogue “please wait, reading locale data“ if it really takes more than one second to open Terminal->Character Encoding->Add or Remove... People don’t go there too often, I presue, at least not as often as opening the terminal, where the “unbearable lag” is now :-)
I agree with comment #3. While deferring the lookup in an idle loop sounds better than doing them during start-up, adding an encoding should be a *very seldomly* operation, so I'd prefer not doing this work at all (if it's not absolutely necessary). Loading the encodings when I chose the menu entry and showing progress in a dialog progress bar (or in the status bar) sounds like an acceptable solution.
When "Terminal->Character Encoding->Add or Remove..." is opened, the lookup could start and populate the list one item at a time with an idle handler. So no proress bar and no startup slow-down.
Created attachment 77548 [details] [review] Comments the while() that apparently creates the lag. This patch is a first test I did to check if there's something gained. I don't know if I commented the right code. I repeat that this is only a test. Opinions please.
Diego, isn't that patch simply disabling all encoding testing?
Yes I know, but as I said it's just for testing if there's a startup speed improvement. I made it after a quick check of the source. So basically I wanted to check if this is worth doing :).
Forgot to say that I didn't get any boost.
This is semi-fixed by not checking all encodings until the enc dialogue is opened. What's the reason for validating the encodings for ASCII-pass-throught? I noticed there are several encodings in our list that will NEVER be valid, e.g. UTF-16 and UTF-32.
This has been fixed.