По поводу интерфейса и работы платформы

Заметил странную штуку, когда открываю pocket option сайт с разых браузеров. В хроме вроде все летает, а в сафари иногда подтупливает график, особенно когда волатильность высокая. Не пойму, то ли это у меня комп старый, то ли реально оптимизацая под разные браузеры хромает. В целом функционал устраивает, но такие мелочи бесят, когда пытаешся быстро зайти в сделку. Кто-нибудь сталкивался с таким? На чем обычно торгуете, чтобы без лагов было?

С Сафари всегда так, он тяжелее переваривает такие скрипты. Просто сиди через Хром и не парься, там оптимизация в разы лучше.

Спорно. Хром жрет оперативку как не в себя, а Сафари на маках обычно работает стабильнее с системой. Если график подтупливает, то дело скорее в самом коде платформы, который криво оптимизирован под разные движки, а не в браузере как таковом. Я пробовал переключаться туда-сюда, и разница есть, но она не настолько критичная, чтобы сразу бежать ставить другой софт. Хотя если волатильность зашкаливает, то лаги действительно бесят, тут согласен. Но советовать просто «не париться» — это так себе решение проблемы. Было бы круче, если бы разработчики просто допилили поддержку всех популярных браузеров, чтобы не приходилось подстраиваться под их технические костыли.

С чего вы взяли, что дело в движках? По-моему, просто кэш забивается или инет проседает. Я на маке сижу, и в Сафари всё летает, пока открыто две-три вкладки. А если начать плодить окна, то любой браузер начнет тупить. Код платформы тут ни при чем, просто железо не резиновое, а оперативка улетает мгновенно.

Слушай, я уже пару недель гоняю эту платформу в Chrome на старом i5‑7300U, и наблюдаю точно то, что ты описал: при трёх‑четырёх открытых вкладках… RAM собирает почти всё, а после этого любой скрипт начинает «тормозить», даже если сеть стабильна. Пару раз чистил кэш вручную – сэкономил лишь несколько мегабайт, но в целом проблема всё равно в том, что движок не «отпускает» память, а просто держит её в резерве. На моём MacBook Pro с Safari всё плавно работает, но там в фоне включен «Memory Pressure Management», который автоматически выгружает неактивные табы. Поэтому, если сравнивать, дело больше в том, как браузер управляет ресурсами, а не в самом коде платформы. Если хочешь, можешь попробовать ограничить количество одновременно открытых окон или включить экспериментальный режим «Tab discarding» в Chrome – заметно снизит нагрузку, хотя полностью избавиться от «пролёта» оперативки не получится без апгрейда железа.

Если честно, я тоже наткнулся на эту же боль, но у меня-то не Chrome, а Edge на том же i5‑7300U, и ситуация кажется почти кристально схожей: после двух‑трёх табов RAM уже начинает «пить» почти всё, а скрипты, которые ранее работали без задержек, вдруг начинают «запинаться», будто бы сеть внезапно пошла в огонёк. Мне удалось отчасти обуздать проблему, отключив автозаполнение и предзагрузку страниц в настройках браузера – это снизило нагрузку на память на 10‑15 %, но полностью избавиться от «залипания» пока не удалось. Интересно, что в Safari на Mac‑е, как отметил ViktorLine34, всё летает ровно, пока открыты две‑три вкладки, и даже при большом количестве вкладок графики не подвисают. Возможно, дело не только в кэше, а в том, как Chrome управляет процессами JavaScript‑воркеров на слабом железе. Я пробовал вынести часть тяжёлых виджетов в отдельные окна, а потом сворачивать их, но даже в этом случае память всё равно росла, просто медленнее. Есть идея попробовать эксперимент с параметром --disable-features=RenderProcessLimit, который ограничивает количество процессов, однако боюсь, что это может ухудшить стабильность в целом. В любом случае, если у кого‑то уже есть «рабочий» набор флагов или проверенный набор расширений, которые помогают держать RAM в узде без потери функций, буду благодарен за наводку – сейчас я уже на пределе своих возможностей, а платформа, безусловно, заслуживает более гладкой работы даже на стареньком ноуте.

Странно, что вы все на i5-7300U сидите, какой-то стандарт пошёл. Но по поводу «запинания» скриптов — это сто процентов утечка памяти в самом коде платформы, а не в браузерах. Edge и Chrome на одном движке, так что Edge тут не спасёт. Виктор, про Сафари — это вообще другое дело, там механизмы управления ресурсами иные. Но когда RAM забивается под завязку, никакое железо не вывезет кривую оптимизацию. Попробуйте просто рефрешить страницу каждые полчаса, помогает временно.

Выглядит так, будто проблема кроется именно в ядре платформы, а не в браузере. Я тоже тестировал на i5‑7300U, но в Firefox‑112 видел почти как‑то стабильный RAM после пяти вкладок, пока в Chrome/Edge он уже «переполнялся». Возможно, часть утечки происходит в модуле рендеринга, который вызывается только у Blink‑основных движков. Если Safari обходится без‑боли, значит их GC работает иначе, а не «чудо‑блок». Стоит запросить у разработчиков профилирование прямо в продакшн‑сборке.

Странно, что Лиса вывозит, хотя обычно она жрет еще больше. Скорее всего, рендеринг в ядре реально кривой и конфликтует с движком Chromium. Попробовал сбросить кэш, но утечка RAM никуда не делась. Похоже, пока разрабы не поправят код, на i5 будет только тормозить.

С чего вы решили, что дело в i5? У меня на Ryzen 5 ситуация один в один: Chrome просто забивает всю память за полчаса, а Firefox держится. Похоже, дело реально в кривом взаимодействии ядра платформы с Chromium, как и писал MaximRush. Сброс кэша тут не поможет, если в самом коде дыра. Разрабам надо оптимизировать рендеринг, а не надеяться, что железо пользователя вытянет этот костыль. Пока не пофиксят утечку RAM, пользоваться будет мучительно.

Смешно вообще, что кто-то пытался списать это на проц. Когда у людей на разных архитектурах один и тот же прикол с утечкой, тут уже до железа дело не доходит. Я сам сижу на Chrome, и если оставить платформу открытой на пару часов, она реально сжирает всё, что есть, пока браузер просто не вылетает с ошибкой памяти. Firefox в этом плане сейчас реально спасает, хотя обычно он более неповоротливый. По поводу «дыры в коде» — скорее всего, так и есть. Похоже на какой-то бесконечный цикл или кривой рендеринг элементов интерфейса, который не очищается из памяти. Пока разрабы не перепишут взаимодействие с Chromium, сброс кэша будет просто имитацией лечения. Нужно требовать фикс ядра, а не гадать с настройками браузера.

Посмеяться можно, но сваливать всё на железо — это вообще детский сад. Когда и на Райзенах, и на Интеле одна и та же картина, становится понятно, что проблема в самом коде. Я вообще перестал держать вкладку открытой дольше часа, потому что Chrome просто задыхается, жрёт всю оперативку и в итоге всё падает. Смешно, конечно, что кто-то пытается оправдать это процом, когда тут явная утечка памяти в самом ядре платформы. Даже если у тебя 64 Гб оперативки, она всё равно заполнится, просто чуть медленнее. Лиса в этом плане сейчас реально спасает, но это же не значит, что проблему решили, просто движок иначе переваривает этот кривой рендеринг. По факту мы сейчас просто гадаем на кофейной гуще, пока разрабы не признают, что у них там в памяти дыра размером с океан. Самое бесячее, что сброс кэша тут вообще не помогает, потому что память течёт в реальном времени. Это не вопрос конфигурации ПК, это вопрос оптимизации интерфейса, который сейчас работает из рук вон плохо. Либо они переписывают взаимодействие с Chromium, либо будем и дальше смотреть, как браузер вылетает с ошибкой нехватки ресурсов каждые пару часов.

Слушайте, ну какой вообще смысл обсуждать архитектуру проца, когда тут явная утечка памяти в самом приложении. Это классика: когда код кривой, хоть суперкомпьютер ставь — всё равно через время всё зависнет. У меня Edge ведет себя точно так же, хотя он вроде как оптимизирован лучше. Бесит больше всего то, что разрабы молчат, а мы тут гадаем, почему Chrome забивает всю оперативку. По факту, проблема в том, что платформа просто не умеет чистить кэш или что-то подобное. Пока не перепишут этот кусок кода, никакое обновление железа не спасет. Единственный вариант сейчас — это реально каждые полчаса рефрешить страницу, но это же костыль какой-то, а не нормальная работа.