Артефакты рендёрига текста в firefox

Проверяй, интересно.

LTO +5%, PGO +20%.

При этом все эти бенчи в основном по времени загрузки, показа нового таба или окна. Интересный основной сценарий использования просмотрщика текста. На тестах js, эти lto и pgo ничего не дают, тк там jit со своей оптимизацией. Плюс к этому на некоторых тестах этот jit проигрывает сборке собранного без jit. И в последних версиях файрфокса сломали сборку без jit. Примерно знаю как починить, но зачем это мне ради каких-то неизмеримых 5%?

загрузки, показа нового таба или окна

что у некоторых составляет немалую часть процесса работы с браузером.

>загрузки, показа нового таба или окна

что у некоторых составляет немалую часть процесса работы с браузером.

Ты тоже веселый.

Серьёзно. Когда я последний раз пробовал пользоваться фаерфоксом в качестве основного браузера, я обнаружил заметные подтормаживания при открытии новой вкладки или преключении вкладок. Это основная причина, удерживающая меня от окончательного перехода на firefox.

Скорость загрузки - безразлично.

На что тренируется Файрфокс с PGO - на открытие файлов с медия контент - webm opus mp4 pdf.

Кстати, вот - познавательно.

Хорошие новости.

Файрфокс в версии 56 - с квантовым ядром - не страдает задержками открытия табов и запуска себя.

Такой баг видел несколько раз года два назад. И замечал его на разных дистрибутивах. И хз как чинить, я просто перезапускал браузер.

Перезапуск не помогает, оно с самого начала так.

Зойчем убирать, скажи пожалуйста?

Артефакты рендёрига текста в firefox (комментарий)

Сейчас буду выяснять, какой именно ключ вызывает проблему.

Вспомнил. Один раз - возникла подобная ошибка с фонтами. Файрфокс, был вовсе не при чём.

Причина была в fontconfig-infinality-ultimate. Нужно было пересобирать именно этот пакет, вместе с harfbuzz.

Но это было так давно, и теперь этот баг исправлен.

В общем, это была векторизация. Что то они в GCC 6.3 сломали. Векторизацию отключил, тему помечаю решённой.

Что то они в GCC 6.3 сломали

Там потребление памяти еще сломали начиная с 5 версии. GCC 6 вообще оборзел, на с++ файле с большим количеством функций и методов может сожрать до 4 гигов, где для gcc4 максиум 200 метров нужно. Замечу, это компиляция одного cpp файла в объектник, а не линковка.

Сколько не проверял этот миф, всегда оказывалось что Os охрененно медленнее _всегда_.

Кэши сейчас большие.

Какое железо? Если видеокарта AMD и используется Mesa, то Mesa 17.2-rc нельзя собирать с march=native для хасвела и выше, там баг, который ломает шейдеры glamor, что может приводить к подобным результатам.

Притворюсь царем и даю рабочий код, почти эмулирующий работу просмотрщика текста в плане производительности с точки зрения пользователя.

#include <unistd.h>
main(){
  while(1)
    usleep(10);
}

Ну возьми пдф на несколько десятков метров, или въеб2.0 сайт формально с текстом. Inb4 нинужно, https://ietf.org/rfc/*.txt наше всёю

Нет, так не пойдет. Ты давай доказывай утверждение _всегда_, а не ищи контрпример к моему контрпримеру, потому что контрпример к моему контрпримеру не доказательство утверждения _всегда_. А комфортность просмотра pdf во всяких разных интернет эксполрерах с дефолтными оптимизациями ничем не хуже от извращенных оптимизаций.

Я явно писал про свой собственный опыт, так что синтетические b и тем более нереалистичные контрпримеры вообще пролетают.

Даже если например врубить подсветку синтаксиса на очень здоровом txt (опустим рассуждение про плохую практику такого), то тоже будет тормозить.

То есть _всегда_ - это твое личное мнение. Тогда зачем ты выделял это слово? Пытаешься давить авторитетом и навязать свое мнение остальным? В моей вселенной твое _всегда_ не работает. А вот мои некоторые рекомендации вроде как помогают во вселенной топикстартера.

То есть бла-бла-бла. Не всегда, а без нереалистичного выжопливания, так и быть. Топикстартер тебя послал кстати.

То есть бла-бла-бла

То есть мои работающие примеры -это бла-бла-бла. Запомню в своем лексиконе: «бла-бла-бла» - это работающие примеры. В дальнейшем буду чаще использовать это слово.

Топикстартер тебя послал кстати.

Но сделал как я рекомендовал. Благодарность она такая.

Твой пример даже не выводит текста, он не работающий, бгг.

Мой пример - это опровержение твоего _всегда_. B легко можно сделать так, чтобы он выводил «Привет моя вселенная».

И это всё ещё не будет просмотрщиком. Кроме того даже это можно заставить тормозить, раз у тебя тут соревнование по выжопливанию.

Ты давай покажи как твои ключи оптимизации могут ускорить до неприличия этот код. У тебя же _всегда_ получится, что там один никчемный пример. Давай показывай свои векторизации, хвостовые рекурсии, ленивые вычисления.

gcc -Dusleep=exit

Ускорение стремится к бесконечности, бгг.

Так и запишем -D - это ключ оптимизации. А если полезная нагрузка кода - это вызов usleep. Сколько вызовов usleep в минуту покажет профилировщик после твоей оптимизации?

Petrosyan.docx

Артур Пирожков знает толк в ключах оптимизации. Наверно еще _всегда_ использует -Dusleep=exit

Тебе уже привели примеры в которых было всегда, читать не умеешь?

У кого и где было? Единственно что могу подтвердить, это только то что с pgo время загрузки файрфокса ускорилась хоть как то заметно. Но веб бенчмарки практически не изменились, +-5%. Хром не пробовал, слишком бессмысленное насилование железа для меня.

нивилируется через е, установи уже спеллчек...

Ну, у меня последний хромиум собирся примерно за 12 часов, гента, рамы 6гб.