Я бы не стал использовать grep
. Вместо этого я бы сравнил имя файла, используя встроенный -в test
оператор ([[
... ]]
), который может напрямую обрабатывать регулярные выражения.
function getname(){
local fname="$1"
[[ -z "$fname" ]] && read -p "Enter a file name: " fname
until [[ "$fname" =~ ^[[:alpha:]] ]] && [[ -f "$fname" ]]
do
[[ -d $fname ]] && echo "Paths are not a legal file name."
read -p "Enter a legal file name: " fname
done
}
Вы можете попробовать полностью отключить грязные кеши, хотя это может привести к довольно неприятным последствиям, т.е. ваша скорость записи может сильно пострадать, потому что они позволяют ядру оптимизировать операции записи, т.е.:
sudo sysctl vm.dirty_background_bytes=4096
sudo sysctl vm.dirty_bytes=8192
Хорошая статья о кэшировании:https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/
time
показывает использование ресурсов дочерним процессом, измеренное ядром; он используетgetrusage
для этого (в Linux, это реализовано с помощьюwait4
. Он измеряет реальное время, используемое конкретным измеряемым выполнением.
Изменения, которые вы видите, отражают изменения, возникающие во время выполнения процесса. Они имеют множество причин, обычно связанных с конфликтом ресурсов того или иного рода. Как и любой тест, использование time
имеет смысл только в предварительно определенном -сценарии.
Попытка измерить время выполнения команды без какого-либо внешнего воздействия (в основном )возможна, но требует больших усилий по настройке. В Linux вы можете предварительно очистить все дисковые кеши:
echo 3 > /proc/sys/vm/drop_caches
(Эффекты запуска процесса нигде больше не кэшируются, за исключением небольшой части кэшей ЦП, если только сам процесс не выполнил свою собственную мемоизацию, чтобы при повторном запуске он выполнял меньше работы — , например. компилятор с ccache
. Вероятно, вы знаете, делает ли это ваше собственное приложение.)
Вы также можете запустить команду, которую хотите измерить, на выделенном ЦП, который в противном случае не использовался бы ядром, чтобы на нее не влияли прерывания или перепланирование, а также в меньшей степени на сброс кэша. Другие факторы, которые следует учитывать, включают колебания частоты процессора, гиперпоточность, рандомизацию адресного пространства...
Один из моих коллег, Виктор Стиннер, написал свои заметки и ссылки на тему бенчмаркинга , сосредоточившись на бенчмаркинге Python; одна ссылка, которая предоставляет хороший набор корректировок, это руководство Дениса Бахвалова по получению стабильных результатов в Linux .