1

The problem

The following code snippet shows the time it took to my system to open inkscape plus the time it took to me to immediately close the inkscape window.

$ /usr/bin/time -p inkscape
real 26.95
user 0.59
sys 0.05

I've read posts (here and here) in which people reports that inkscape takes too much to start but the answers relates this problem with the number of fonts installed in the user's system.

As far as I know, I can get the number of fonts installed in my system with the following command (see below). So, the number of fonts installed in my system is not the problem here.

$ fc-list | wc -l
105

I tried looking at the strace command output and found the tasks which are slowing down the process of opening inkscape. (I'm not sharing the complete log of strace because it is reporting the name of some personal files among all the output.)

$ strace --absolute-timestamps=ns inkscape
...
13:27:03.700577007 read(11, "\1\0\0\0\0\0\0\0", 16) = 8
13:27:03.700603187 poll([{fd=11, events=POLLIN}], 1, 25000) = 0 (Timeout)
13:27:28.725932887 write(11, "\1\0\0\0\0\0\0\0", 8) = 8
13:27:28.726024537 futex(0x55ca60dcb240, FUTEX_WAKE_PRIVATE, 2147483647) = 0
...

As you can see above, there are 25 seconds between two tasks, so this definitely has to do with the problem.

The question

What is the poll system call doing and how can I reduce the time it takes to my system to execute that system call?

PD1: I tried searching poll([{fd=11, events=POLLIN}], 1, 25000 on Google and found this question in which the poster explains that GTK3 applications are starting slowly and relates this misbehavior with the fact that strace shows a system call that is taking too much time (which is the same as the one presented in this post) but I didn't found the answers helpful.

gfe
  • 191
  • 9
  • 1
    Earlier in the output you'll likely see a system call such as `open` with `= 11` at the end of the line. That tells you what file descriptor 11 is. Knowing that will help you understand this issue better. – steve May 20 '20 at 18:52

1 Answers1

2

That particular syscall isn't doing anything per se. It's waiting for something else to do something, in particular, for data to become available to read on FD 11. To figure out why it's not getting the data it's waiting for, you need to check what that FD is connected to and find what's supposed to be writing to the other end of it.

And by the way, this question that you found is extremely helpful, and you should reread it more carefully and try again to heed its advice, rather than dismissing it so quickly.

Joseph Sible-Reinstate Monica
  • 3,298
  • 14
  • 27
  • 1
    Thanks. I reread the replies to the mentioned question and solved the issue. The following statement from the Arch Wiki had the answer: "At the very least, ensure that the last if block in `/etc/X11/xinit/xinitrc` is present in your `~/.xinitrc` file to ensure that the scripts in `/etc/X11/xinit/xinitrc.d` are sourced." For those wondering, the last `if` in my system contains a `for` loop which sources files with extension `.sh` from the `/etc/X11/xinit/xinitrc.d` directory. – gfe May 24 '20 at 17:22