оптимизация вызова программ

[ifori]

Написал скрипт на bash. Вообще-то не один. Проблема вышла : слишком медленно работает... Может быть есть какая-то программа, которая говорит ядру, что надо некоторые программы в оперативу записать и читать их оттуда каждый раз а не из винта. Я знаю, что есть кэш в системе и всё такое. И ядро всякую оптимизацию проводит. Но этого мало. Может посоветуете чего?

[korisk]

Написал скрипт на bash. Вообще-то не один. Проблема вышла : слишком медленно работает... Может быть есть какая-то программа, которая говорит ядру, что надо некоторые программы в оперативу записать и читать их оттуда каждый раз а не из винта. Я знаю, что есть кэш в системе и всё такое. И ядро всякую оптимизацию проводит. Но этого мало. Может посоветуете чего?

Как вариант, можно сделать виртуальный диск, расположенный в памяти, (ключевое слово tmpfs), туда скопировать часто вызываемые програмулины.
Но не факт, что поможет.
Удач.

[ifori]

Про ram диск мне известно - trinux на этом вылезла... Дело в том, что программы, которые юзаются скриптом - всё равно на винте установлены...
Попробуйте такой скрипт запустить и вы прозреете от такой скорости:
if((${BASH_ARGV[0]}==0));then
exit 0;
fi
((arg=${BASH_ARGV}-1));
echo $arg;
bash_test.sh $arg&
exit 0;



Запуск такой:
bash_test.sh 10000
Это же черепаха с ампутированными ногами....

[altwazar]

Все эти махинации с памятью ради подобного скрипта нужны?

[altwazar]

Если да, то:
1. Скрипты на баш вообще быстротой не отличаются.
2. Скрипт написан криво, замена рекурсии на for ускорит его выполнение раз в сто.
3. Работу этого скрипта обычно делает встроенная в оболочку функция {1000..1}

[ifori]

Если да, то:
1. Скрипты на баш вообще быстротой не отличаются.
2. Скрипт написан криво, замена рекурсии на for ускорит его выполнение раз в сто.
3. Работу этого скрипта обычно делает встроенная в оболочку функция {1000..1}

Так эта рекурсия показывает слабое место bash...
Я этот скрипт так написал специально.
Когда я запускаю этот скрипт с электронного диска, скорость выполнения уменьшается на одну секунду. Причём я не только скрипт, но и сам bash засунул в электронный диск. Я думал мне тут смогут подкинуть прогу, которая такой диск создаёт, сканирует чего программа юзает, которую нужно оптимизировать, создаёт символические ссылки перед выключением и после загрузки на файлы, которые юзаются... Чот-то в этом духе мне надо. Никто не знает?

[Portnov]

Нужна скорость - пишите на чём-нибудь побыстрее. Шелл никак не оптимизируется по производительности (нет такой задачи у разработчиков).

[ifori]

Вот блин...
У меня есть такая задача.
У меня огромное количество скриптов, которые должны работать быстрее, чем сейчас.
А писать на чём-то другом - даже на Perl - Геморой.
Вот вопрос - есть такой замечательный язык, как bash. На нём многие вопросы решаются за несколько минут. А вместо этого предлагается часами сидеть за компом и долго думая стучать по клавишам, набирая прогу - отстой.
Надо же с этим что-то делать

[drBatty]

Нужна скорость - пишите на чём-нибудь побыстрее. Шелл никак не оптимизируется по производительности (нет такой задачи у разработчиков).

от Вас не ожидал такого ответа...
скрипт - он и есть скрипт.

Вот вопрос - есть такой замечательный язык, как bash. На нём многие вопросы решаются за несколько минут. А вместо этого предлагается часами сидеть за компом и долго думая стучать по клавишам, набирая прогу - отстой.
Надо же с этим что-то делать

ну...
вы простите, но тупой скрипт - тупо работает.
хороший скрипт работает хорошо.
это относится к ЛЮБОЙ программе, на любом языке. Кстати, мне написать скрипт - дольше...

ЗЫЖ странно, у меня в скриптах 99% времени уходит НЕ на вызов команд... а на их выполнение...

[altwazar]

У меня огромное количество скриптов, которые должны работать быстрее, чем сейчас.

Можно посмотреть конкретный скрипт?

А писать на чём-то другом - даже на Perl - Геморой.

От задачи зависит. Когда не хватает баша применяю питон, думаю перл тоже подойдет (его не пробовал).

Вот вопрос - есть такой замечательный язык, как bash. На нём многие вопросы решаются за несколько минут. А вместо этого предлагается часами сидеть за компом и долго думая стучать по клавишам, набирая прогу - отстой.
Надо же с этим что-то делать:)

Баш хорошо подходит для создания макета программы.
Обычно баш скрипты создают что бы связать другие программы.
Тут перенос программ в оперативную память не особо поможет даже, это можно проверить загрузившись с live cd поместив его полностью в память.

хороший скрипт работает хорошо.
это относится к ЛЮБОЙ программе, на любом языке. Кстати, мне написать скрипт - дольше...

Ну не всегда. Иногда язык не очень хорошо подходит к конкретной задаче.

[Sleeping Daemon]

Вот блин...
У меня есть такая задача.
У меня огромное количество скриптов, которые должны работать быстрее, чем сейчас.
А писать на чём-то другом - даже на Perl - Геморой.
Вот вопрос - есть такой замечательный язык, как bash. На нём многие вопросы решаются за несколько минут. А вместо этого предлагается часами сидеть за компом и долго думая стучать по клавишам, набирая прогу - отстой.
Надо же с этим что-то делать

Посмотрите в сторону "sticky bit" для исполняемых файлов.

[altwazar]

Посмотрите в сторону "sticky bit" для исполняемых файлов.

Я могу ошибаться, но он же вроде уже давным давно как не используется. Сейчас же вроде это все автоматизированно, и повторный запуск и так происходит быстро.

[drBatty]

А вместо этого предлагается часами сидеть за компом и долго думая стучать по клавишам, набирая прогу - отстой.

дык писать на си - не так долго. некоторые вещи быстрее и проще решаются на си, некоторые скриптом...
обычно и писать на баше почти не нужно, уже всё есть, только соединить.

Ну не всегда. Иногда язык не очень хорошо подходит к конкретной задаче.

конечно.
например довольно глупо создавать программу на си:

Код: Выделить всё

int main()
{
 system("man man");
 system("exit 0");
 return 0;
}

Посмотрите в сторону "sticky bit" для исполняемых файлов.

какая разница?
программы и так маленькие, критичных участков 1, и размера 20%, всё и так в памяти...

[korisk]

Посмотрите в сторону "sticky bit" для исполняемых файлов.

Добавлю, свои пять копеек
В википедии написано:
the Linux kernel ignores the sticky bit on files. [Linux chmod(1)]
Авторитетный источник

[altwazar]

думая стучать по клавишам, набирая прогу - отстой.
Надо же с этим что-то делать:)

дык писать на си - не так долго. некоторые вещи быстрее и проще решаются на си, некоторые скриптом...
обычно и писать на баше почти не нужно, уже всё есть, только соединить.

Это не моя цитата :) Я тоже самое ответил, только чуть другими словами.

[ifori]

Optimizator ya napisal(na tom zhe bash'e). Pravda teper na translite pishy : neskolko raz sistemy perestavlyal:). Teper drugaya problema:
Est takoi file v sisteme:
/lib/libc-2.5.so, kotoruy vesit 1.4mb.
Ya ego peregonyau na elektronnuy disk, no lsof vse ravno mne vudaet starue puti:
vmesto /mnt/ramdisk/12 - /lib/libc-2.5.so
Podozrevayu, chto sistema ego vse ravno s vinta chitaet(swap razdel ili chto-takoe).
Pochemu s vinta - potomu chto kogda napryamuyu bash v elektronnuy disk kopiruyu - proizvoditelnost uvelichivaetsa... A tak ne hochet.
Chego posovetuete?
Prikrepil ishodniki dla sozdaniya svyazei. Ne poluchilos. Sdelayu po drugomu:
link_make.pl:

Код: Выделить всё

#!/usr/bin/perl
if($#ARGV != 1) {
    print "Expcted two arguments\n";
    exit 1;
}
open(CP,"cp '$ARGV[0]' '$ARGV[1]'|");
while(<CP>) {
    print $_;
}
close CP;
unlink $ARGV[0];
symlink($ARGV[1],$ARGV[0]);

link_del.pl:

Код: Выделить всё

#!/usr/bin/perl
if($#ARGV != 1) {
    print "Expcted two arguments\n";
    exit 1;
}
unlink $ARGV[0];
open(FROM,'<',$ARGV[1]);
open(TO,'>',$ARGV[0]);
while(read(FROM,$buf,100)) {
    syswrite(TO,$buf);
}
close(FROM);
close(TO);
@arr = stat $ARGV[1];
unlink $ARGV[1];
$perm = $arr[2] & 07777;
chmod $perm,$ARGV[0];

[drBatty]

Это не моя цитата Я тоже самое ответил, только чуть другими словами.

да, конечно. пост исправил, прошу прощения за ошибку

[ifori]

Так не подскажите чего делать? Я уже много времени над этим делом просидел. Когда я переношу файл на электронный диск то такие программы как vim, быстрее этот файл читают. А вот системные файлы и библиотеки разные не хотят быстрее грузиться, Почему? Откликнитесь линуксоиды!!!!! Вы мне конечно много чего насоветовали, но всё как бы не совсем то - или переходи на другой язык или ещё чего-то делай только не так, как тебе хочется....

[coopht]

Так не подскажите чего делать? Я уже много времени над этим делом просидел. Когда я переношу файл на электронный диск то такие программы как vim, быстрее этот файл читают. А вот системные файлы и библиотеки разные не хотят быстрее грузиться, Почему? Откликнитесь линуксоиды!!!!! Вы мне конечно много чего насоветовали, но всё как бы не совсем то - или переходи на другой язык или ещё чего-то делай только не так, как тебе хочется....

Вам надо чтобы программы быстрее запускались?
Посмотрите в сторону Preload и Prelink.

Если ваш скрипт не сильно уж сложный, то попробуйте
shc - Generic shell script compiler

Избавьтесь от рекрусии, везде где только возможно.

[drBatty]

Когда я переношу файл на электронный диск то такие программы как vim, быстрее этот файл читают

потому что они КАЖДЫЙ раз читаются с диска.

А вот системные файлы и библиотеки разные не хотят быстрее грузиться, Почему?

давайте суда РАЗМЕР файлов читаемых вимом, и этих скриптов/библиотек. библиотеки вообще почти всегда разделяемые и УЖЕ загруженные, программы грузятся один раз, скрипты маленькие. Про что именно вы пишете?
дайте вывод команды time vim файл, что-бы все увидели. А так - просто рассуждения.

[Rootlexx]

Есть ещё способ немного повысить скорость «запуска» программ: указывать к ним полные пути, чтобы BASH не приходилось искать по всем каталогам из PATH.
Тестов не проводил, насколько поможет, не знаю.

[drBatty]

Есть ещё способ немного повысить скорость «запуска» программ: указывать к ним полные пути,

а вот ещё один:
help hash
правда в этом есть смысл если у вас в $PATH сотни путей, и пентиум 1(ИМХО)

[neol]

А кеш на процессоре быстрее оперативной памяти ;) Ничуть не менее бесполезная и проктологичная оптимизация.

[drBatty]

А кеш на процессоре быстрее оперативной памяти Ничуть не менее бесполезная и проктологичная оптимизация.

причём тут кеш на процессоре??
это кеш bash. им можно управлять, что-бы кешировались нужные вам команды(точнее пути к ним)
только я вот не знаю(не очень интересно), кешируются-ли команды в самом скрипте?
кроме того, в самом bash имеется отладчик, и даже вроде профилировщик, почитайте man bash. Мне это не слишком нужно, в силу того, что в моих скриптах 90-99% времени уходит не на сам bash