Реалистичные оценки времени для индикаторов выполнения и т. Д. - PullRequest
16 голосов
/ 27 марта 2009

Я знаю, что я не единственный, кому не нравятся индикаторы выполнения или оценки времени, которые дают нереальные оценки в программном обеспечении. Лучшими примерами являются установщики, которые прыгают с 0% до 90% за 10 секунд, а затем для завершения последних 10% требуется час.

В большинстве случаев программисты просто оценивают шаги для выполнения задачи, а затем отображают currenttstep / totalalsteps в процентах, игнорируя тот факт, что для выполнения каждого шага может потребоваться другое время. Например, если вы вставляете строки в базу данных, время вставки может увеличиться с количеством вставленных строк (простой пример), или время копирования файлов зависит не только от размера файла, но и от расположения на диск и насколько он фрагментирован.

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

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

Кто-нибудь знает о передовых решениях этой проблемы?


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


EDIT : Я могу придумать, как вручную настроить оценку времени, и даже с «библиотекой оценки» мне придется настроить алгоритм. Но я думаю, что эту проблему можно решить с помощью статистических инструментов. Конечно, оценщик будет собирать данные во время процесса, чтобы создать более точные оценки для следующих шагов.

Теперь я беру среднее время, затраченное на предыдущий шаг (шаги, сгруппированные по типу и нормализованные, например, по размеру файла, размеру транзакции) и принимаю это среднее значение как оценку для следующих шагов (опять же: подсчет в разные виды и размеры).

Теперь я знаю, есть лучшие статистические инструменты для создания оценщиков, и мне интересно, применял ли кто-нибудь их для решения проблемы.

Ответы [ 7 ]

8 голосов
/ 27 марта 2009

Будучи старшекурсником, Джулиан Миссиг и я провели эксперимент, мало чем отличающийся от Harrison et al. бумага. Как и следовало ожидать для проекта класса, мы не получили достаточного количества данных, чтобы заявить о себе, за исключением того, что в течение 5-секундного интервала отсутствие индикатора выполнения фактически воспринималось как короче .

Итак, если задача может занять меньше, чем, скажем, 10 секунд, лучше вообще не показывать индикатор выполнения. Это не значит, что вы не должны показывать никакой обратной связи, но индикатор выполнения, скорее всего, сделает его медленнее.

Если вам интересно, у Джулиана есть бумага и плакат на его сайте.

7 голосов
/ 27 марта 2009

Слава Богу, я не единственный!

Я не знаю библиотеки, которая обрабатывает оценки, но я могу лично поручиться за ваши идеи профилирования. Однажды я реализовал индикатор выполнения, который использовался, чтобы сообщить о ходе долгой, сложной файловой операции (несколько небольших файлов читались, обрабатывались, а затем объединялись в больший файл). У меня было программное обеспечение, которое отслеживало время, затрачиваемое на чтение, запись и обработку, а затем соответственно корректировало индикатор выполнения. После того, как программа была запущена пару раз, индикатор выполнения стал плавным, как шелк. Никаких пауз и быстрых вспышек.

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

4 голосов
/ 27 марта 2009

Я не думаю, что проблема в том, что они оценивают количество шагов настолько, что часто используется неправильное определение «шага». В вашем примере программы установки с 0 до 9% за 10 секунд, а затем за час до конца, я видел, как это произошло, когда программист решил подсчитать количество копируемых файлов, а не количество байтов.

Скажем, было 10 файлов, по 9 из них по 5 КБ (readme, лицензия, значок и т. Д.), А последним был ISO-образ 2 Гб, ну, первые 9 будут копироваться очень быстро, а последние будут медленными! Считать файлы было неправильно, надо было посчитать байты. Проблема в том, что если вы хотите подсчитать байты, вам нужно реализовать собственную процедуру копирования, чтобы вы могли предоставлять обновления статуса во время копирования большого файла. Стоит ли реализовывать собственную подпрограмму копирования?

Другая проблема заключается в том, что установка (как и многие другие) состоит из стеков подпрограмм, которые могут быть довольно глубокими. Эти подпрограммы могут делать много вещей, но они, вероятно, являются общими подпрограммами, и в них нет ничего, что могло бы обновить какой-либо индикатор прогресса на гораздо более высоком уровне. Вам потребуется переопределить ряд распространенных процедур, чтобы получить хорошую информацию о прогрессе.

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

3 голосов
/ 27 марта 2009

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

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

Скачать обновление
Остановить запущенные процессы
Обновление программного обеспечения
Настройка программного обеспечения
Перезапустить программу

Отдельные задачи хороши, потому что производительность в прошлом сильно указывает на производительность в будущем. Первые 10 секунд загрузки, скорее всего, покажут, сколько времени занимает оставшаяся часть файла. То же самое с самим обновлением.

Для более коротких процессов не требуется индикатор выполнения, поэтому даже не отображайте его ни в одном процессе, пока этот процесс не займет 10 секунд или более. Таким образом, пользователь в быстрой системе просто видит галочку в каждой задаче, а в медленной системе пользователь видит галочки, и если он остается над задачей «слишком долго», он получает индикатор выполнения с действительно полезной информацией.

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

Очень полезно иметь общее «приблизительное оставшееся время» внизу, которое охватывает наилучшее предположение для всех задач, но я бы не стал показывать это на индикаторе выполнения.

Что касается индикаторов выполнения, они предназначены для линейного перемещения. Когда они прыгают и заикаются, это очень расстраивает пользователя - на самом деле они менее полезны и в этом случае дают неверную информацию.

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

-Adam

2 голосов
/ 26 ноября 2009

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

Я использую таблицу базы данных для хранения своих исторических данных. Я перестраиваю свою функцию оценки на основе последних 100 записей в таблице.

У меня есть аннотации по долгосрочным методам определения переменной, определяющей скорость.

YMMV, но в следующий раз оценка учитывает это.

2 голосов
/ 27 марта 2009

Другой (и гораздо более простой способ) состоит в том, чтобы просто дополнить оценку и восприятие пользователя.

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

Если я жду задания, и оно завершается на 50% за 10 секунд - я расстраиваюсь, когда для завершения последних 50% требуется еще 20 секунд.

Для той же задачи, если она достигает 50% за 30 секунд, продолжает идти до 60% - и затем волшебным образом прыгает до 100% - я удивлен, но не раздражен.

Если задача действительно короткая или совершенно непредсказуемая, то также работает некоторый анимированный цикл (значок загрузки браузера, анимация ожидания iPhone и т. Д.).

Если вы находитесь в паре случаев, когда вам действительно нужна точность - тогда, вероятно, стоит потратить некоторое время на код для повышения надежности индикатора.

2 голосов
/ 27 марта 2009

Как вы говорите, у вас может быть 100 шагов, но каждый из этих шагов займет различное количество времени в зависимости от того, что они делают.

Один из подходов состоит в том, чтобы группировать задачи по тому, что они делают (удаление, изменение значений реестра, загрузка, копирование файлов и т. Д.) И для каждой группы, назначая некоторые ключевые свойства:

  • Какие метрики применяются для мониторинга (скорость копирования, скорость распаковки и т. Д.)?
  • Какова средняя наихудшая частота для этого процесса?

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

  1. Распаковка файла по 100мг (группа: распаковка, значение: 100)
  2. Копирование 120 мг (группа: копия, значение: 120)
  3. Настройка значений реестра (группа: реестр, значение: 25)
  4. Очистить (группа: удаление, значение: 100)

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

Microsoft потребовалось десятилетие, чтобы сделать это правильно, поэтому не расстраивайтесь, если сначала это не сработает =)

...