To build or not to build? Вот в чём вопрос!

 В своей предыдущей заметке new.kv.by/content/optimizatsiya-prilozhenii-v-ubuntu я рассказал, как можно прооптимизировать приложение в Ubuntu. При этом сделал акцент на полезность оптимизации для обработчиков медиафайлов. В своём мнении я опирался на информацию из Интернета, проверить не удосужился.  Вопрос, заданный мне в комментариях,  был закономерен: а насколько улучшится скорость перекодировки? Наконец, я нашёл немного времени, чтобы ответить на этот конкретный вопрос.

Итак, пусть мы имеем "матрёшечный " файл mmm.mkv и нам надо его перекодировать в AVI. Конечно, прежде всего надо уметь замерять время выполнения программы. В Линуксе делается это с помощью команды time, параметром которой является имя выполняемой утилиты. Однако, тут есть небольшая заморочка: параметр должен быть представлен одним словом, в то время, как ffmpeg всегда имеет кучу собственных параметров. Поэтому определить время выполнния команды строкой time ffmpeg -i mmm.mkv mmm.avi не получится. К тому же замеры придётся производить моногократно... Но ведь у нас Линукс! С помощью оболочки bash командная строка ffmpeg -i mmm.mkv mmm.avi элементарно сворачивается в одну команду. Для этого любым редактором (я предпочитаю штатный gedit) создаём файл вроде этого:

#!/bin/bash

sudo ffmpeg -i mmm.mkv mmm.avi

exit

 

Затем сохраняем его в домашней директории, например, под именем doitt. Делаем этот файл исполняемым: открываем "Наутилус", правый клик по файлу, далее идём "свойства-права" и помечаем чекбокс "позволять выполнение файла, как программы". Запускать скрипт надо не как doitt, а как ./doitt, иначе скрипт будет искаться системой по путям, прописанным в переменной окружения $PATH и, естественно, найден не будет. Итак, приступим:

 time ./doitt

Через некоторое время утилита ffmpeg прекратит работу и на экран поступит сообщение вроде этого:

real 0m18.901s

user 0m11.433s

sys 0m0.432s

Нас интересует только строка, поименованная, как user, в которой содержится время, затраченное  на выполнение пользовательского задания. Чтобы уменьшить погрешность оценки, необходимо команду time ./doitt  запускать несколько раз, каждый раз  фиксируя результат, например, 7 раз. Затем надо отбросить максимальное и минимальное значение времени и вычислить арифметическое среднее. Для неоптимизированной ffmpeg и mkv-клипа длиной 3 минуты 35 с у меня получилось 11,386 c (под Windows -- больше на пару секунд, но, возможно, я делал что-то не так). Компьютер -- посредственный 2-х-ядерник P31-DS3L при 1800 МГц на ядро. После оптимизации с уровнем 2 это время уменьшилось на 1,34%, с уровнем 3 -- на 1,89%. В действительности это время уменьшается ещё больше, так как на величину пользовательского времени влияет и скорость обмена с диском, которая в данном случае никак не оптимизируется (для этого надо пересобирать ядро). 

Резюме: 1) в Линуксе оценивать время выполнения даже очень тяжёлой утилиты весьма просто, 2) оптимизация ffmpeg не даёт преимуществ настолько, чтобы ею заниматься.

Однако, есть одно НО. Если у вас HD-медиафайл проигрывается "с тормозами" -- всё же попробуйте прооптимизировать проигрыватель. Возможно, вам не хватает всего какого-то единственного процента производительности. Помогает! На форумах рассказывали. :)

Михаил Гурчик

gor-mike@tut.by

 

 

Версия для печатиВерсия для печати

Рубрики: 

  • 1
  • 2
  • 3
  • 4
  • 5
Всего голосов: 0
Заметили ошибку? Выделите ее мышкой и нажмите Ctrl+Enter!

Читайте также

 

Комментарии

Аватар пользователя Alandr

 Спасибо, Михаил!

Все-таки, выходит, что выигрыш от оптимизации находится в пределах погрешности измерения - "1,34% ... 1,89%". Жаль 

Аватар пользователя mike

Погрешность измерения легко уменьшается числом измерений. Ускорение в самом деле есть, однако оптимизация ffmpeg требует закачки 420 Мбайт, длится минут 40, что, собственно, и отвечает на вопрос "билдить или нет": билдить, если уж очень-очень надо. Но, думается, чем билдить в Ubuntu, то лучше перейти на Gentoo. 

 

 

 

Аватар пользователя Alandr

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

Аватар пользователя mike

В ближайшее время статью не планирую, так как со временем опять напряг. В каждом конкретном случае изменения надо смотреть в  директории /var/cache/apt-build/build в файле с расширением changes. И разбираться. Будет время -- займусь. Самому интересно.

Аватар пользователя Alandr

 В каждом конкретном случае изменения надо смотреть

Т.е. вы хотите сказать, что каждый раз используются разные подходы? Занятно... Я думал, что используется несколько стандартных техник, вроде: если проц двухъядерный - делаем так, если четырех - так, если памяти 2Гб - такая оптимизация, если 4Гб - сякая.