Издержки системного вызова times () - относительно файловых операций - PullRequest
0 голосов
/ 01 июля 2010

Какова относительная нагрузка при вызове times() по сравнению с файловыми операциями, такими как чтение строки fread().

Я понимаю, что это, вероятно, отличается от ОС к ОС и зависит от того, какова длина строки, где находится файл, действительно ли это заблокированный канал (это не так) и т. Д.

Скорее всего, файл не локальный, а находится на смонтированном диске NFS где-то в локальной сети. Распространенным случаем является строка длиной 20 символов. Если это поможет, предположим, что ядро ​​Linux 2.6.9. Код будет не работать в Windows.

Я просто ищу приблизительное руководство. Это того же порядка? Быстрее? Медленнее

Конечная цель: я смотрю на реализацию процедуры обратного вызова хода выполнения, но не хочу звонить слишком часто (поскольку обратный вызов, вероятно, очень дорогой). Большая часть работы заключается в чтении текстового файла (строка за строкой) и выполнении чего-либо со строкой. К сожалению, некоторые строки имеют длину очень , поэтому простой вызов каждых N строк не эффективен в слишком часто встречающихся патологических случаях.

Я избегаю писать тесты, потому что боюсь писать неправильно и надеюсь, что мудрость толпы превосходит мои полуготовые тесты.

Ответы [ 3 ]

3 голосов
/ 01 июля 2010

fread() - это функция библиотеки C, а не системный вызов. fread(), fwrite(), fgets() и друзья по умолчанию являются буферизованными ввода-выводами (см. setbuf ), что означает, что библиотека выделяет буфер, который уменьшает частоту, с которой read() и write() необходимо выполнить системные вызовы.

Это означает, что если вы последовательно читаете из файла, библиотека будет выполнять системный вызов только, скажем, через 100 операций чтения (в зависимости от размера буфера и объема данных, которые вы читаете за раз).

Однако при выполнении системных вызовов read() и write() они определенно будут выполняться медленнее, чем вызов times(), просто из-за объема данных, которыми необходимо обмениваться между вашей программой и ядром. Если данные кэшируются в буферах ОС (например, они были записаны другим процессом на той же машине несколько минут назад), то они все равно будут довольно быстрыми. Если данные не кэшируются, вам придется ждать ввода-вывода (будь то на диск или по сети), что очень медленно по сравнению.

Если данные обновляются по NFS, то я был бы уверен, что вызов times() будет в среднем быстрее fread().

2 голосов
/ 07 июля 2010

В Linux вы можете написать небольшую программу, которая выполняет множество вызовов times () и fread () и измеряет время системного вызова с помощью strace -c

* 1003 например *

for (i = 0; i < RUNS; i++) {
        times(&t_buf);
        fread(buf,1,BUF,fh);
}

Это когда BUF 4096 (fread будет фактически вызывать read () каждый раз)

# strace -c ./time_times
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 59.77    0.001988           0    100000           read
 40.23    0.001338           0     99999           times

а это когда BUF 16

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 99.00    0.001387           0     99999           times
  1.00    0.000014           0       392           read
1 голос
/ 01 июля 2010

times () просто читает поддерживаемые ядром данные, специфичные для процесса.Данные поддерживаются ядром для предоставления информации для системного вызова wait () при выходе из процесса.Таким образом, данные всегда поддерживаются, независимо от того, вызывается ли когда-либо время ().Дополнительные издержки на вызовы times () действительно низкие

fread (), fwrite () и т. Д. Вызывают базовые системные вызовы - read () и write (), которые вызывают драйверы.Затем драйверы помещают данные в буфер ядра.Это намного дороже с точки зрения ресурсов, чем вызовы times ().

Это то, что вы спрашиваете?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...