Почему чтением является ФАЙЛ быстрее, чем чтение ПЕРЕМЕННОЙ?
Я не понимаю результаты простого теста производительности, я запустил использование двух основных скриптов (работающий на высокопроизводительном сервере):
perfVar.zsh:
#!/bin/zsh -f
MYVAR=`cat $1`
for i in {1..10}
do
echo $MYVAR
done
perfCat.zsh
#!/bin/zsh -f
for i in {1..10}
do
cat $1
done
Результат тестирования производительности:
> time ./perfVar.zsh BigTextFile > /dev/null
./perfVar.zsh FE > /dev/null 6.86s user 0.32s system 100% cpu 7.177 total
> time ./perfCat.zsh BigTextFile > /dev/null
./perfCat.zsh FE > /dev/null 0.01s user 0.10s system 91% cpu 0.118 total
Я думал бы, что доступ к ПЕРЕМЕННОЙ был путем быстрее, чем чтение ФАЙЛА в файловой системе... Почему этот результат? Существует ли способ оптимизировать perfCat.zsh сценарий путем сокращения количества доступов к файловой системе?
0 ответов
Я смог воспроизвести то же поведение в Bash. Основная проблема здесь состоит в том, что Вы используете переменные оболочки способом, что они не были разработаны для; и поэтому не оптимизированный для. При действительно 'повторении $HUGEVAR' оболочка должна создать командную строку, содержащую все содержание $HUGEVAR (даже при том, что 'эхо' является встроенной командой, существует все еще командная строка).
Таким образом, оболочка разворачивает HUGEVAR в большую строку, которая затем анализируется снова для разделения его на пробеле в список отдельных аргументов команде эха. (Обратите внимание, что это будет иметь эффект сворачивания последовательных пробельных символов во входном файле к символам одиночного пробела). Очевидно, этот процесс не очень эффективен с большими строками.
Необходимо просто использовать метод 'кошки bigfile' многократно; и позвольте кэшу файловой системы ОС делать свое задание и ускорять повторный доступ большого файла; Вы избегаете тонкого (возможно нежелательный) модификация к строке, которую оболочка делает при использовании эха (плюс метод 'кошки', будет работать с двоичными файлами, где метод оболочки мог повредиться на двоичных данных).
В ударе и csh, переменном выборе...
#!/usr/bin/env bash
MYVAR=`cat $1`
#!/usr/bin/env tcsh
set myvar=`cat $1`
... заставит это выполняться cat команда, а также любая интерпретация текста, который может произойти. Как пример, если переменная среды ЛЕНГ установлен на UTF8, или если это превращает новые строки в пробелы. Наконец, это должно выделить место для хранения результата cat.
В отличие от этого, сценарий № 2 просто кошки файл и сделан с ним. На самом деле, так как это пишет в /dev/null, это, вероятно, улучшит производительность также.
Попытайтесь писать в файл вместо /dev/null и повторно синхронизируйте его. Это почти наверняка будет быстрее все еще, но синхронизации могут больше соответствовать друг другу.
Наконец, имейте его время просто цикл вместо того, чтобы синхронизировать весь сценарий. Если то, что Вы хотите сделать, время, читая из переменной-vs-читающий из файла, то Вы не синхронизируете его правильно.
править
Для синхронизации, вместо того, чтобы использовать time команда я рекомендовал бы делать это:
#!/usr/bin/env bash
# do some stuff
date --rfc-3339=ns
for (( i = 0; i < 10; i++ )); do
# Some more stuff
done;
date --rfc-3339=ns
Это произведет текущую дату и время с точностью до наносекунды.
Переменное присвоение (в отличие от большей части другого созданного-ins сценария) является дорогой операцией. Причина Вы видите такое решительное различие в производительности, состоит в том, потому что размер данных Вы работаете с. На поверхности появляется, как будто Вы только присваиваете данные, после того как к единственной переменной (MYVAR), но в действительности zsh присваивает данные временному местоположению (отображающаяся и не отображающаяся память) на каждом вызове эха. Обычно это не проблема, но при работе с большим блоком данных, это становится примечательным.
Причина цикл кошки выше, два, сворачиваются. Размер данных и кэширование файловой системы.