делаю примерно также. гугл+промт и лингво+mt. есть еще бинг с яндексом, но те послабее.
если пишу сразу на английском, то забываю is, the и прочие «лишние» слова.
у меня уже лет 20 один из паролей (мастер-пароль) — достаточно известная фраза из фильма. с элементами народного фольклора (т.е. мата). применяется там, где вводить нужно редко, так что для запуска винды не подойдет.
Ничто не мешает браузеру менять поведение 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++, но оказалось, что он не всегда находит самые эффективные методы упаковки
а какие компиляторы сами раскидывают поля по структурам/классам?
ну теперь-то дело пойдет быстрее. вопрос: вот найдем разумных чуваков. сколько времени понадобится чтобы получить от них (любыми способами) технологию емких и дешевых аккумуляторов?
если пишу сразу на английском, то забываю is, the и прочие «лишние» слова.
Но идея интересная. Можно вызывать 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/
а какие компиляторы сами раскидывают поля по структурам/классам?
зачем в ПЗУ нужен Монитор если есть СР/М?