Заранее извиняемся за заголовок, но именно с такой формулировкой эта история ворвалась к нам с легкой руки журналистов Forbes, которые на самом деле сделали то, что было не под силу пользователям в течение нескольких лет. А теперь подробнее о проблеме в Google Chrome и ее истории.
Что такое tick rate?
Есть в операционной системе Windows такой параметр как system clock tick rate. Он определяет с какой частотой система выходит из "простоя" и отслеживает события. Например, по умолчанию параметр равен 15,625 мс. Т.е. каждые 15 мс (или, по другому говоря, 64 раза в секунду) система "просыпается". Очевидно, что чем чаще это происходит, тем больше на это нужно ресурсов и энергии, но в ряде случаев это имеет смысл делать, чтобы добиться большей точности, плавности, например, при просмотре видео. Поэтому программы имеют возможность изменять этот параметр (причем переключается он глобально для всей системы), но должны делать это гибко и возвращаться к прежнему показателю после завершения задач.
А чем не угодил Chrome?
А тем, что браузер Google Chrome вполне успешно присваивает этому параметру значение 1 мс (т.е. 1000 раз в секунду "будит" систему), но совершенно забывает возвращаться к исходному состоянию. В результате при запущенном браузере вся система начинает потреблять как минимум на 25% больше энергии (согласно Microsoft), что, конечно же, не сильно радует владельцев ноутбуков, у которых, как известно, аккумуляторы не резиновые.
А теперь немного истории
Проблема эта знакома разработчикам браузера практически с момента его появления в 2008 году. А начиналось все с решения уйти от 15 мс, потому что это очень медленно и не современно.
Windows timers by default will only fire with a period of ~15ms. While processor speeds have increased from 500Mhz to 3Ghz over the past 15 years, the default timer resolution has not changed. And at 3GHz,15ms is an eternity.
И понять их можно. На современном десктопе с достаточно мощным железом браузер, который уже успел превратиться из программы для отображения текстовых страниц с гиперссылками в средство для запуска сервисов, игр и приложений, не мог развернуться в полную силу. Чем быстрее срабатывают таймеры, тем быстрее выполняется те или иные задачи, например, сортировка текста. Вот вам визуальная демка сего процесса.
Именно тогда разработчики познакомились с системной функцией timeBeginPeriod(), которая и позволяет программам уменьшать период вплоть до 1 мс. К сожалению, тут были свои недостатки:
- Этот параметр изменялся для всех программ и процессов в системе.
- А еще это влияло на способность системы уходить в спящий режим с низким потреблением энергии.
Взглянув на эти минусы, разработчики чуть было не плюнули на все это дело, но спас их плагин Adobe Flash Player, который, как оказалось, уже давно использует именно этот способ для повышения частоты, равно как и другие плагины, например, Windows Media Player или QuickTime. Именно их успешный пример позволил отбросить все страхи и включить 1 мс по умолчанию в браузере Chrome...
Вот только потом оказалось, что на некоторых сайтах это вызывает проблемы. Например, на сайте мало кому известной газеты NewYork Times это изменение вступало в конфликт с одним js-файлом. Поэтому пришлось искать решение проблемы и его нашли в том, что умерили свои аппетиты и вместо 1 мс стали менять параметр на 4 мс. Что, кстати, тоже показало хорошие результаты в сравнении с отправной точкой. Вот результаты той самой демки, ссылку на которую давали выше.
А еще совсем забыли про ноутбуки, для которых такое поднятие частоты приводило к значительному повышению энергопотребления. Пришлось делать исключение для аккумуляторов, что и было сделано в декабре 2008 года.
Но кажется, кто-то где-то что-то забыл...
Уже в 2010 году появляются сообщения о том, что Google Chrome непозволительно много потребляет энергии при работе на ноутбуке. А в 2012 году создается репорт, который подтверждается разработчиками в том же году, но благополучно забывается до июля 2014 года, когда статья журналиста Forbes привлекает к проблеме внимание всего мирового сообщества. И в тот же день баг-репорт берут в работу и повышают ему приоритет.
Работа над проблемой идет и по сей день, несмотря на заявления некоторых СМИ о том, что ее уже исправили. И даже если она будет исправлена в Chromium прямо сейчас, вряд ли стоит ждать исправленную стабильную сборку раньше, чем выйдет 38 версия браузера, т.е. как минимум через три месяца.
Какие выводы можно сделать после прочтения?
1. За каждым технологическим достижением скрывается потенциально обиженный журналист Forbes.
2. Ничто так не повышает приоритеты, как широкая публичная огласка.
3. Админу Хром.рф в пятницу вечером совсем нечего делать и он пишет вот эту статью.