MR18: полное сканирование показывает мало реалистичный прогресс и прогноз окончания

[Michel]

Окно Full Scan показывает статус сканирования «99%, осталось меньше минуты» когда было проверено 850К файлов, с тех пор прошло еще минут 10-15, проверено еще ≈300К файлов и только потом сканирование закончилось:

Edited May 11 by Michel

[kmscom]

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

[Michel]

1 hour ago, kmscom said:

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

Ни в коем случае! Мне важно хотя бы примерно понимать сколько времени еще ждать окончания проверки. А вот сама цифра сколько файлов проверено как раз роли не играет — какая разница проверено 850К или 1,2М файлов? Что это меняет?

Edited May 11 by Michel

[andrew75]

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

Так что эти проценты в любом случае ни о чем.

[kmscom]

9 часов назад, Michel сказал:

850К или 1,2М файлов?

это число тоже не точное, потому что если попадется архив с 10 файлами, будет показано 10, а для вас это 1

собственно @andrew75 уже все сказал.
@Michel запускайте проверки , тем более полную, перед тем как выключить ПК и идите спать

[Michel]

5 minutes ago, andrew75 said:

Так что эти проценты в любом случае ни о чем.

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

• размера проверяемых файлов
• количества файлов
• скорости чтения файлов
• скорости оперативной памяти
• мощности и нагрузки процессора

то можно рассчитать вполне точно.

Edited May 11 by Michel

[kmscom]

3 минуты назад, Michel сказал:

использовать статистику проверок миллионов пользователей

 это примерно как угадать комбинацию джекпота в лотерею, по статистике выигрышных

 

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

[Michel]

Just now, kmscom said:

 это примерно как угадать комбинацию джекпота в лотерею, по статистике выигрышных

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

[kmscom]

2 минуты назад, Michel сказал:

Все-таки статистика — это вполне себе точная наука.

тогда можете строить прогнозы на основе ваших предыдущих проверок и будете 

19 минут назад, Michel сказал:

понимать сколько времени еще ждать

 

[andrew75]

Еще раз - количество и тип файлов заранее неизвестны.

Поэтому с чем собственно сравнивать, если нет достоверных исходных данных?

 

[Michel]

9 часов назад, andrew75 сказал:

Еще раз - количество и тип файлов заранее неизвестны.

А если просто по размеру проверяемых файлов, это ведь можно получить от ОС?

Скажем, по итогам 10 млн сканирований на компах с SSD, и процессорами i5 проверка 80 гигов данных заняла 13 минут и 27 секунд, а дальше уже использовать эту статистику (временной коэффициент) для расчета времени проверки для конкретного юзера?

9 часов назад, kmscom сказал:

тогда можете строить прогнозы на основе ваших предыдущих проверок и будете

Хотелось бы, чтобы этим занимался продукт, а не пользователь

[andrew75]

3 минуты назад, Michel сказал:

а дальше уже использовать эту статистику (временной коэффициент) для расчета времени проверки для конкретного юзера?

вы получите некое среднее значение, которое может никак не коррелировать с вашим конкретным случаем.

[Michel]

5 minutes ago, andrew75 said:

вы получите некое среднее значение, которое может никак не коррелировать с вашим конкретным случаем.

Верно, но чем больше данных, тем точнее прогноз, хотя и про overfitting забывать не стоит.

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

Edited May 11 by Michel

[kmscom]

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

[Michel]

6 minutes ago, kmscom said:

Можно конечно просто писать, время продолжительности последней проверки

Это крайне неточная метрика, особенно, если при прошлом сканировании не использовались системы оптимизации (iSwift, iChecker), а в текущем — используются или наоборот (первая проверка после свежей установки vs. последующие проверки или проверка после долгого перерыва).

 

6 minutes ago, kmscom said:

вызывает только недовольство, даже тех, кто хочет понимать сколько ждать

Это плохо, удовлетворение клиента — это цель.

Edited May 11 by Michel

[kmscom]

4 минуты назад, Michel сказал:

удовлетворение клиента — это цель.

не получая неточные данные, он будет удовлетворен.

 

4 минуты назад, Michel сказал:

Это крайне неточная метрика

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

[andrew75]

15 минут назад, kmscom сказал:

Можно конечно просто писать, время продолжительности последней проверки, из отчета

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

[KOTGDI]

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