С недавних пор мы стали использовать самописные скрипты на PowerShell. Все они опубликованы в нашем репозитории на GitHub, можете перейти по ссылке и ознакомиться с их содержимым и предложить свои правки в случае, если увидите ошибку.
Собственно, я для того и публикую свои скрипты, чтобы, если кто заметит за мной ошибку, меня о ней оповестили, запушив Pull Request, и я своевременно мог её исправить. И только поэтому я в каждом текстовом обзоре ноутбука ссылаюсь на наш репозиторий на GitHub. Там нет никакой рекламы, мы никак с гитхаба не зарабатываем и никакой иной мотив помимо улучшения нашей методики тестирования мы не преследуем (к слову, думаю в ближайшие недели опубликую её отдельной статьёй, пока сильно загрузен).
К сожалению, вышло так, что никто не заметил эту ошибку и, соответственно, никто меня о ней не оповестил, поэтому ноутбуки Acer Nitro 5 и Dell XPS 17 мы протестировали неправильно, и только сейчас, приступая к тестам следующего ноутбука, мы заметили, что при работе скрипт для логгирования заряда батареи во время теста автономности, вызывает повышенный расход этого самого заряда (ноутбук со скриптом разряжается в 3-4 раза быстрее). Сразу после обнаружения я написал об этом Стасу, дал краткое разъяснение сути ошибки и он опубликовал об этом пост в группе ВК и в сообществе YouTube, приложив туда то самое краткое разъяснение. А ниже мы чуть более подробно разберём её суть.
Собственно, что же это за ошибка такая? Сперва разберёмся с тем, что у нас за скрипт, какую задачу он выполняет. Цель проста: каждые 10 секунд проверять, изменился ли заряд батареи, и, если изменился, записывать через точку с запятой в файл “battery_test_log.txt” % заряда батареи и время, в которое изменившийся заряд был зафиксирован. Например, в 15:05:50 мы запустили скрипт и заряд батареи составлял 100%, а в 15:07:30 скрипт обнаружил, что заряд составляет уже 46%. Тогда в файл будет записано на одной строчке “99;15:07:50”, а на другой – “46;15:07:30”. Далее мы всё это дело сгружаем в Excel и считаем простыми формулами средний расход аккумулятора за минуту (%/мин), за сколько минут в среднем расходуется 1% (мин/%) и среднюю скорость разряда в Ваттах, и общее время работы (или время, затраченное на зарядку ноутбука).
Звучит просто, но, тем не менее, я умудрился допустить ошибку, сунув ожидание в 10 секунд между проверками заряда в условие “если заряд изменился”. Соответственно, если заряд не менялся, то буквально сразу же после опроса и проверки проходила ещё 1 проверка, и так по кругу. И в результате вместо опроса заряда батареи и сопоставления его с предыдущим сохранённым значением раз в 10 секунд, мы получили 25 опросов в 1 секунду. Т.е. скрипт опрашивал заряд аккумулятора в 250 раз чаще, чем должен был. Это данные с моего Xiaomi Mi Notebook Pro GTX, у других ноутбуков может быть больше/меньше. Как вы понимаете, это вызвало повышенный расход заряда аккумулятора и поэтому ноутбуки Acer Nitro 5 и Dell XPS 17 на деле жили меньше, чем должны были жить. В связи с этим я принял решение из сравнительной таблицы удалить их результаты по тесту автономности. Результаты останутся в статьях с обзором, но с пометкой, что на деле ноутбуки должны жить дольше. Все последующие ноутбуки мы уже будем тестировать с исправленной версией скрипта.

Ссылка на коммит на гитхабе с внесёнными правками:
https://github.com/ZChuckMoris/ikakprosto/commit/084f155ba786b2664c4e10650b958341acc1b1a5
Заодно, раз уж взялся за редактуру, внёс ещё одну правку доп. проверкой в этом же коммите: теперь, если файл “battery_test_log.txt” уже существует (например, если Вы запустили тест автономности, после завершения ноутбук выключился, вы его включили и сразу же запустили тест скорости заряда батареи), файл не будет перезатёрт, просто новые данные допишутся в его конец.

Также спасибо Виталию Голованову за его советы по доработке скрипта в комментариях к записи Стаса в ВК с отчётом об ошибке. После его советов я доработал скрипт и запушил ещё 1 коммит. Из изменений: добавил обработку исключений и внёс небольшие косметические изменения в код.
Update: в следующем, уже 3-ем коммите, исправил выход из цикла (заменил pause на break, чтобы происходит выход из цикла, а не пауза, которая и так нас ждёт в конце скрипта).
В общем, разобрались, теперь код скрипта поправлен, выглядит красивенько, если есть у Вас какие-то предложения по доработке этого или других скриптов, милости прошу на GitHub, я только рад буду Вашим Pull Request`ам. Если предложенные Вами правки будут значимыми, я тут же их внесу, а если нет, я в культурной форме поясню, почему отклонил Ваш Pull Request.
Приношу извинения перед теми, кто полагался на наши результаты тестов автономности при рассмотрении к покупке Acer Nitro 5 и Dell XPS 17. Некоторые люди в комментариях к записи Стаса в ВК и записи в сообществе YouTube писали, что стоит сделать перетест в таком случае, но, к сожалению, это не представляется возможным, т.к. оба ноутбука мы уже сдали. Мы можем лишь исправить свою ошибку и следующие тесты провести уже правильно, и именно этому и посвящена данная статейка.
Спасибо за то, что уделили время чтению этой статьи. Я это ценю. В дальнейшем такие статейки будут выходить каждый раз, когда буду сам обнаруживать у себя ошибку.
Первый коммент под статьёй!))
Что-ж, ошибки всегда бывают, мы на них учимся и продолжаем развиваться, по крайней мере так должно быть. А вам удачи и прямых рук в написании кода.
Спасибо, что уделил внимание статейке и спасибо за пожелания с:
Вот зачем эта вся **отня с PShell, можно на Python сделать почти такой-же скрипт, даже меньше затратив усилия.
Могу помочь c этим во имя святого Саса.
tg: @BrenOnes
затем, что интерпретатор Python ещё нужно установить на ОС Windows, а PowerShell идёт из коробки.
Какая разница, на чём скрипт написан, если свою задачу он выполняет? Сейчас с ним проблем нет. На обработку команды расходуется около 10-50 мс в зависимости от железа раз в 10 секунд. Это от 1/1000 времени выполнения скрипта до 1/200. Допустим, на Python будет 5-25 мс, ну и что это поменяет? 1/200 это и так незначительное значение. Можно скомпилировать программу на С++ и получить царские 0.1-0.5 мс или 1-5 мс в крайнем случае, но суть одна: что с PowerShell нагрузка на железо минимальная, что с Python, что с C++. Да, выигрыш будет, но на общем фоне в 10 секунд ожидания между вызовами эта нагрузка вообще ни на что не влияет. И снова вопрос: зачем тут что-либо переписывать?
Если ты сможешь мне пояснить, в чём существенная выгода пользователю скрипта от того, что скрипт будет переписан с PowerShell на Python, не вопрос, я его сам перепишу.
видимо больше людей знает питон чем повершелл.
время на написание скрипта на питоне уйдет меньше.
скрипт уже написан и он сейчас нормально функционирует. Не понимаю, в чём смысл его сейчас переписывать на Python