Комментарии 7
Хм, а зачем считать процент от всего времени? Ведь линковка и поиск всего-всего происходит обычно при старте, а посему, насколько я понимаю, вполне возможно, что пара-тройка секунд при старте очень даже симпатишно поможет порадоваться жизни, а все остальное время как раз можно и не учитывать. Так что тест — он какбэ необъективен, ибо мешает в кучу разные вещи. Думаю стоит посчитать отдельно время на загрузку, а те миллисекунды, что набегают при использовании — они действительно ни о чем.
Есть один тонкий момент: я рассмотрел не однопоточное приложение типа «Hello, World», а многопоточную и достаточно сложную систему (всё ещё называющуюся web-браузером), посему сумма времени всех неудавшихся вызовов в реальности будет даже меньше 4 секунд. Полагаю, что выяснить это можно лишь записывая время в unix epoch с точностью 1e-6 для каждого вызова, и посмотреть пересечения.
Поиск библиотек происходит на старте, совершается линковщиком, который так или иначе делает системные вызовы, а значит, его вызовы тоже попадают в трассировку. Если выполнить тест повторно, но уже с временем вызова, то можно сегментировать [неудачные] вызовы по времени от запуска приложения.
Поиск библиотек происходит на старте, совершается линковщиком, который так или иначе делает системные вызовы, а значит, его вызовы тоже попадают в трассировку. Если выполнить тест повторно, но уже с временем вызова, то можно сегментировать [неудачные] вызовы по времени от запуска приложения.
С суммированием 40 тысяч значений отлично справится bc, а данные ему можно передать через paste:
cat z.fail.timing | paste -sd '+' - | bc
Счётчик системных вызовов (в пятой колонке — ошибки)
Там же и сумма
$ 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
Поскольку исходный топик более недоступен, не могли бы вы добавить пару слов, в чем собственно заключался предмет исследования, и как readahead связан с неудачными сисколлами?
Автор первого топика задался исследованием количества (именно количества) неудачных сисколов, и предположил, что приложения будут загружаться ощутимо быстрее, если в тех местах, где программа ищет в первую очередь (upd: не только либы, но и локали, звуки, картинки, et cetera), создавать симлинки на вполне себе существующие файлы. Вкратце и не вдаваясь в подробности и философию, это было так.
PS: readahead ощутимее добавляет прирост производительности за счёт кэширования, нежели «симлинкинг» всего и всюду.
PS: readahead ощутимее добавляет прирост производительности за счёт кэширования, нежели «симлинкинг» всего и всюду.
readahead ощутимее добавляет
Закон Сохранения [ вставить по вкусу ] — если где-то прибыло, значит где-то убыло. :)
Есть фича Copy-on-Write, но она вроде только на ext2 работает.
Вот такой костыль ещё есть
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Экономия на спичках, или Неуловимый Джо возвращается