Отображение индикатора выполнения приводит к замедлению времени выполнения
Я пишу много внутренних скриптов, которые автоматизируют задачи для команды. Чтобы они не задавались вопросом, «остановился» ли сценарий, я показываю простой индикатор выполнения для длительно выполняемых задач. Я делаю это, потому что могу измерить завершенное количество, так как я знаю количество, требующее завершения перед запуском. Чтобы сэкономить на количестве выполняемых операций, я обновляю индикатор выполнения только каждые nсекунды или при запуске / завершении задачи.
Я обнаружил, что существует компромисс между:
- пользовательский опыт (зная, что задача выполняется)
- время завершения общего сценария
Если добавить шаги, чтобы получить индикатор выполнения и держать их в курсе, задача может занять в 2 раза больше времени.
В общем, является ли это ожидаемым компромиссом (возможно, не для других языков, а для Python)?
Ответы
Это очень хороший вопрос.
В целом, мы всегда уделяем первоочередное внимание пользовательскому опыту.
Пример: поисковые системы рейсов могут предоставлять результаты мгновенно, но они загружаются дольше, поскольку пользователи чувствуют себя в большей безопасности после тщательного поиска.
Когда дело касается в 2 раза медленнее. 2x, вероятно, нормально, если это пара секунд, и, вероятно, ужасно, если это будет годами. Все зависит от контекста ваших пользователей. Если работа вашего сайта - это вопрос жизни или смерти, то быстрее - лучше, если ваши пользователи более расслаблены со временем, которое требуется, и для них важнее знать, когда проверять, а затем сообщать им, что ожидаемое время будет лучший вариант.
Сделай это быстрее, когда
- Доказано, что время загрузки отрицательно влияет на принятие, использование, надежность, доверие и т. Д.
- Скорость - это вопрос жизни или смерти
- Скорость - это вопрос заработка (например, клиентам по телефону нужен срочный ответ)
Показать полосу загрузки, если
- Умножение времени на два не приведет к тому, что пользователи полностью отключатся.
- Пользователи могут позволить себе подождать, пока, вероятно, займутся чем-то другим.
Еще кое-что, что следует учитывать. Возможно, вам нужно гибридное решение, в котором для некоторых процессов вы получаете полосу загрузки, а для некоторых - нет.
Возможно, вам понадобятся альтернативные варианты: например, показать панель загрузки и сообщить пользователям, что, скрыв ее, они могут ускорить задачу, спросить пользователей, хотят ли они получить уведомление по электронной почте, когда задача будет готова и т. Д.
В любом случае, лучше всего было бы увидеть, что пользователи предпочтут в соответствии с их контекстом и потребностями.
Но удачи вам, это очень интересная задача. Сообщите, какое решение вы выбрали в конце. :)
Проще говоря, любая программа, выполняющая действие и показывающая индикатор выполнения (т.е. два действия), будет использовать больше процессоров, чем программа, выполняющая только одно действие.
Однако это не означает, что настенные часы обязательно должны быть медленнее. Фактически, двукратное замедление imho кажется излишним.
Некоторые стратегии включают:
- Не отображается индикатор выполнения (на самом деле это значение по умолчанию для большинства команд Unix, где вам нужно будет добавить подробный параметр)
- Предоставление тихой опции для отключения индикатора выполнения. На самом деле это должно быть предусмотрено для пользовательского интерфейса (например, предположим, что пользователь будет запускать его из cron или перенаправлять вывод в файл), но будет иметь побочный эффект в виде обхода замедления индикатора выполнения.
- Отображение прогресса в другом потоке. Наверное, сложно работать с Python, но нормально с другими языками. У вас есть поток графического интерфейса, показывающий вам некоторый прогресс, и рабочий поток, выполняющий фактическую работу.
- Уменьшение интервала обновления индикатора выполнения / размера шага.
- Если вы копировали файл побайтово (в качестве аргумента, это явно неэффективно), вместо того, чтобы перерисовывать индикатор выполнения каждый байт, вы, возможно, захотите обновлять его только после каждого копирования МБ.
- Или по затраченному времени, например, установка таймера, который будет обновлять статус каждые X секунд (опять же, предпочтительно асинхронно с основным действием или в другом потоке).
- Сделав индикатор выполнения как можно более дешевым. Это может перейти от вывода только точек, а не полноценного индикатора выполнения, к тому, чтобы индикатор выполнения был «нарисован» и избегал повторного вычисления его на каждом шаге (однако вы должны выполнять полную обработку на SIGWINCH)
В общем, это ожидаемый компромисс?
В общем, я думаю, это зависит от того, можно ли этого избежать. Если мы загружаем один большой файл из Интернета, вы почти всегда можете уместить соответствующий индикатор выполнения, поскольку загрузка будет выполняться с использованием разных ресурсов. Если вы хотите скопировать файлы с удаленной, медленной файловой системы (например, смартфона), просмотр всего дерева каталогов, которое необходимо скопировать, чтобы отображался индикатор выполнения7, вероятно, потребует ресурсов (пропускная способность соединения с телефоном), которые можно было пропустить, если файлы были найдены и скопированы «в том виде, в каком они есть».