Не изобретайте велосипед. Вы можете использовать pigz
, параллельную реализацию gzip
, которая должна быть в репозиториях ваших дистрибутивов. Если это не так, вы можете получить его у здесь .
Установив pigz
, используйте его как обычноgzip
:
pigz *txt
Я протестировал это на 5 30-мегапиксельных файлах, созданных с помощьюfor i in {1..5}; do head -c 50M /dev/urandom > file"$i".txt; done
:
## Non-parallel gzip
$ time gzip *txt
real 0m8.853s
user 0m8.607s
sys 0m0.243s
## Shell parallelization (same idea as yours, just simplified)
$ time ( for i in *txt; do gzip $i & done; wait)
real 0m2.214s
user 0m10.230s
sys 0m0.250s
## pigz
$ time pigz *txt
real 0m1.689s
user 0m11.580s
sys 0m0.317s
100 МБ — это не так уж много, я читал лог-файлы размером -гигабайт.
Но если файл состоит из большого количества крошечных строк, и если редактор загружает их в буферы несколько большего размера, это приведет к значительному увеличению объема оперативной памяти результата. Я не знаю kedit
, но kate
, например, загружает ~100-мегабайтный файл (10M 10 -строк байт )в 1,3 ГБ оперативной памяти, поэтому я предполагаю, что он использует 128 -. ] байтовые буферы.
И как только вам не хватает оперативной памяти, вся система переключается, и это влияет на все приложения.
Но для подтверждения этого ответа используйте ksysguard
и проверьте общее использование RAM/Swap и использование памяти вашим редактором.