Экономия на спичках, или Неуловимый Джо возвращается

[eaa]

Хм, а зачем считать процент от всего времени? Ведь линковка и поиск всего-всего происходит обычно при старте, а посему, насколько я понимаю, вполне возможно, что пара-тройка секунд при старте очень даже симпатишно поможет порадоваться жизни, а все остальное время как раз можно и не учитывать. Так что тест — он какбэ необъективен, ибо мешает в кучу разные вещи. Думаю стоит посчитать отдельно время на загрузку, а те миллисекунды, что набегают при использовании — они действительно ни о чем.

[KrD]

Есть один тонкий момент: я рассмотрел не однопоточное приложение типа «Hello, World», а многопоточную и достаточно сложную систему (всё ещё называющуюся web-браузером), посему сумма времени всех неудавшихся вызовов в реальности будет даже меньше 4 секунд. Полагаю, что выяснить это можно лишь записывая время в unix epoch с точностью 1e-6 для каждого вызова, и посмотреть пересечения.

Поиск библиотек происходит на старте, совершается линковщиком, который так или иначе делает системные вызовы, а значит, его вызовы тоже попадают в трассировку. Если выполнить тест повторно, но уже с временем вызова, то можно сегментировать [неудачные] вызовы по времени от запуска приложения.

[BasilioCat]

С суммированием 40 тысяч значений отлично справится bc, а данные ему можно передать через paste:
cat z.fail.timing | paste -sd '+' - | bc

[pavlinux]

Счётчик системных вызовов (в пятой колонке — ошибки)

$ strace -f -c google-chrome | sort -k5 -n;  

% time     seconds  usecs/call     calls    errors syscall
  0.00    0.000000           0        20         1 lstat
  0.00    0.000000           0        57         1 fcntl
  1.09    0.000336           1       278         1 openat
 22.90    0.007074          22       317         1 poll
  0.83    0.000257           1       478         2 ioctl
  0.00    0.000000           0        10         3 connect
 34.50    0.010656        1332         8         4 wait4
  0.00    0.000000           0         5         5 mkdir
  1.12    0.000345           1       403         5 read
  0.26    0.000079           1        95        35 access
  2.24    0.000692           1       719        57 open
  0.49    0.000152           0       368       258 recvfrom
  2.06    0.000636           0      1372       582 stat

Там же и сумма

100.00    0.045787                  8026       955 total

[catharsis]

Поскольку исходный топик более недоступен, не могли бы вы добавить пару слов, в чем собственно заключался предмет исследования, и как readahead связан с неудачными сисколлами?

[KrD]

Автор первого топика задался исследованием количества (именно количества) неудачных сисколов, и предположил, что приложения будут загружаться ощутимо быстрее, если в тех местах, где программа ищет в первую очередь (upd: не только либы, но и локали, звуки, картинки, et cetera), создавать симлинки на вполне себе существующие файлы. Вкратце и не вдаваясь в подробности и философию, это было так.

PS: readahead ощутимее добавляет прирост производительности за счёт кэширования, нежели «симлинкинг» всего и всюду.

[pavlinux]

readahead ощутимее добавляет

Закон Сохранения [ вставить по вкусу ] — если где-то прибыло, значит где-то убыло. :)
Есть фича Copy-on-Write, но она вроде только на ext2 работает.
Вот такой костыль ещё есть