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

Некоторым может показаться данный вопрос не существенным: в самом деле, какие бы ни были назначены приоритеты для  одновременно выполняющихся задач их общее время выполнения останется неизменным.

Мы постараемся продемонстрировать, что мы теряем не обращая внимания на приоритеты с помощью небольшой программы на Perl. Программа niced_forks.pl написана с учётом рекомендаций выработанных в статье "Сообщения об ошибках". Она принимает в качестве аргументов приоритеты для запускаемых процессов (числа от -20 для самого приоритетного процесса до 19 для наименее приоритетного процесса). Все процессы выполняют одни и те же действия, но каждый последующий процесс будет повторять их в 4 раза больше раз чем предыдущий. При завершении процесс сообщает свой номер и время, которое ему понадобилось для выполнения.

Для демонстрации мы будем запускать 5 процессов.

Сперва мы попробуем запустить их с одним и тем же нулевым приоритетом:

$ ./niced_forks.pl 0 0 0 0 0
Process 1. 0.074 seconds!
Process 2. 0.390 seconds!
Process 3. 1.507 seconds!
Process 4. 4.360 seconds!
Process 5. 10.323 seconds!

Во-вторых запустим их с нарастающим приоритетом (т.е. процессы требующие большего времени будут выполняться вопреки рекомендациям из теории массового обслуживания с большим приоритетом):

$ ./niced_forks.pl 8 6 4 2 0
Process 1. 0.468 seconds!
Process 2. 1.155 seconds!
Process 3. 2.818 seconds!
Process 4. 5.661 seconds!
Process 5. 10.139 seconds!

При этом отчётливо видно, что время выполнения последнего (самого долгого) процесса практически не изменилось, зато время выполнения более коротких процессов возросло от 6 раз (для самого короткого процесса) до 30% (для 4-го процесса).

Теперь попробуем запустить процессы с уменьшающимся приоритетом, чего и требует теория:

$ ./niced_forks.pl 0 2 4 6 8
Process 1. 0.031 seconds!
Process 2. 0.259 seconds!
Process 3. 1.019 seconds!
Process 4. 3.491 seconds!
Process 5. 9.528 seconds!

Наш эксперимент с единственным замером на самом деле не вполне чист, но множественные замеры лишь подтверждают, что лишь изменяя приоритеты мы можем добиться уменьшения времени выполнения коротких процессов на 30-50% практически приближая их ко времени выполнения на абсолютно не загруженной машине.

В unDE хотелось бы добиться, чтобы каждая задача имела свою оценку нужных ей ресурсов таких как:

При этом под задачей понимается задача поставленная пользователем перед системой и при выполнении, которой не понадобиться более никаких данных от пользователя. Например, задачей является "открыть документ" (время запуска приложения до момента, когда оно будет готово принимать команды пользователя), "сохранить документ", "повернуть изображение". Выполнение же целого процесса такого как oowriter задачей не является, так как реально при его работе пользователь постоянно вводит новые команды и только он определяет, когда он закончится.

Это позволит:

Естественно, что практически невозможно с точностью до секунды определить время выполнения произвольной задачи. А даже если возможно, то часто это требует времени столько же сколько сама задача. Для сокращения этого времени можно индексировать такие данные как размер директорий и некоторые другие полезные при оценке времени выполнения задачи. Для увеличения информативности пользователю желательно выдавать не только оценку времени, но и предполагаемую точность этой оценки. Кроме прочего это поможет избежать ситуации каждую секунду меняющейся оценки, ведь если следующая оценка укладывается в погрешность заложенную в предыдущей, то её значение можно и не менять.

Конечно, все эти преимущества во многом пока только желаемые. Но в проекте unDE мы детально исследуем этот вопрос и опишем в будущих статьях.