Ничто не мешает браузеру менять поведение GC в зависимости от типа питания. В моем случае питание было от розетки. И расширение предназначено для настольных компов.
Но идея интересная. Можно вызывать navigator.getBattery() и не использовать трюки если питание от аккумулятора.
Сейчас проверил, как Chrome 58 ведет себя в условиях нехватки памяти. Во время работы расширения запустил в фоне утиль, который в цикле выделяет, заполняет и тут же освобождает почти всю свободную оперативную память. Результат: в файл подкачки ушло примерно 400 МБ, кэш винды упал до нуля, а процесс с расширением… все также бодро лопает почти 500 МБ. Может бы и дальше продолжил расти, у меня сейчас нет времени долго тесты гонять.
культ карго чистой воды, отзывчивость системы достигается не снижением этих цифр, а стабилизацией их значений
Если система стоит на HDD, то в вышеприведенной ситуации об отзывчивости можно только мечтать.
omahaproxy.appspot.com говорит, что коммит попал в версию 52. Если ошибка до сих пор присутствует, то наверное нужно создать новую issue. А может будет достаточно отписаться в старой.
Я в статье привёл два примера, когда стратегия «вся свободная память — моя память» (кстати, популярная как раз в эпоху MS-DOS) не всегда работает. Дополню.
Допустим, браузер забил всю оперативку мусором. Другое приложение тоже ориентируется на количество свободной памяти. Оно видит, что памяти нет, и выделяет для некой своей операции буфер пониженного размера, что приводит к понижению производительности. Или выделяет такой же объём, допустим гигабайт, а операционная система, чтобы удовлетворить требование, перемещает часть занятой памяти (занятой мусором) в файл подкачки. В этот момент браузер видя, что памяти маловато, наконец начинает убирать мусор, только уже поздновато…
но тогда стОит заняться написанием патчей для этой платформы, а не конструированием костылей на уровне выше.
В идеальном мире, где у людей куча свободного времени — да. В реальном, написать костыль + пнуть разработчиков в багтрекере намного быстрее.
Я привёл в статье ссылку на chromium issue 713344, в которой процесс разрастался до 3.5 ГБ. Если запустить тот пример (переместив с диска в инет) в нескольких вкладках, то процесс падает из-за недостатка памяти. Причём падает 64-битный браузер, похоже у него где-то в коде есть лимит на 4 ГБ на процесс.
можно заставить лису разгонять таймер: https://greasyfork.org/en/scripts/3508-fix-firefox-smooth-scrolling
странно что эта проблема до сих пор у кого-то есть. в этом году в лисе таки починили синхронную прокрутку, по крайней мере в винде. в многопроцессорной лисе должна заработать асинхронная прокрутка, которая в теории еще больше улучшает плавность: https://hacks.mozilla.org/2016/02/smoother-scrolling-in-firefox-46-with-apz/
>>за счёт лучшей упаковки полей в узлах синтаксического дерева, которое генерирует парсер. Раньше этим занимался по возможности компилятор C++, но оказалось, что он не всегда находит самые эффективные методы упаковки
а какие компиляторы сами раскидывают поля по структурам/классам?
ну теперь-то дело пойдет быстрее. вопрос: вот найдем разумных чуваков. сколько времени понадобится чтобы получить от них (любыми способами) технологию емких и дешевых аккумуляторов?
никогда раньше на слышал и не встречал, чтобы в Си (и Си++) писали 4[arr]. специально сейчас проверил, думал на тип ругнется. не, сожрал.
меня еще в Си удивляет, что имя в объявлении структуры — это не тип.
а есть ли статистика, какой процент людей настраивает размер содержимого страницы выбором шрифта? мне кажется, удобнее использовать масштабирование операционной системы (смена DPI) или масштабирование браузера (например ctrl+ и ctrl-). 16px — это крупновато.
что представляют собой плоские камни, на которых мы живём (тектонические плиты), как работает эта штука для руления самолётом (устройства управления в кабине пилота авиалайнера) и что за маленькие мешочки с водой, из которых мы состоим (клетки).
я надеюсь, там объяснения не в стиле «скрипочка — это ящичек, на котором натянуты кишочки, а по ним водят волосиками, и они пищат (с) »?
Но идея интересная. Можно вызывать navigator.getBattery() и не использовать трюки если питание от аккумулятора.
Если система стоит на HDD, то в вышеприведенной ситуации об отзывчивости можно только мечтать.
omahaproxy.appspot.com говорит, что коммит попал в версию 52. Если ошибка до сих пор присутствует, то наверное нужно создать новую issue. А может будет достаточно отписаться в старой.
Допустим, браузер забил всю оперативку мусором. Другое приложение тоже ориентируется на количество свободной памяти. Оно видит, что памяти нет, и выделяет для некой своей операции буфер пониженного размера, что приводит к понижению производительности. Или выделяет такой же объём, допустим гигабайт, а операционная система, чтобы удовлетворить требование, перемещает часть занятой памяти (занятой мусором) в файл подкачки. В этот момент браузер видя, что памяти маловато, наконец начинает убирать мусор, только уже поздновато…
В идеальном мире, где у людей куча свободного времени — да. В реальном, написать костыль + пнуть разработчиков в багтрекере намного быстрее.
Я привёл в статье ссылку на chromium issue 713344, в которой процесс разрастался до 3.5 ГБ. Если запустить тот пример (переместив с диска в инет) в нескольких вкладках, то процесс падает из-за недостатка памяти. Причём падает 64-битный браузер, похоже у него где-то в коде есть лимит на 4 ГБ на процесс.
javascript / dom в лисе пока «однопоточные».
странно что эта проблема до сих пор у кого-то есть. в этом году в лисе таки починили синхронную прокрутку, по крайней мере в винде. в многопроцессорной лисе должна заработать асинхронная прокрутка, которая в теории еще больше улучшает плавность: https://hacks.mozilla.org/2016/02/smoother-scrolling-in-firefox-46-with-apz/
а какие компиляторы сами раскидывают поля по структурам/классам?
зачем в ПЗУ нужен Монитор если есть СР/М?
меня еще в Си удивляет, что имя в объявлении структуры — это не тип.
я надеюсь, там объяснения не в стиле «скрипочка — это ящичек, на котором натянуты кишочки, а по ним водят волосиками, и они пищат (с) »?
и чем он лучше indexOf?
И самый цимес – разрешат оставлять запятую у последнего члена массива
сейчас тоже можно, если речь идет о [1,2,]