Слухи про глючность Сафари в основном слышу от любителей Андроида, Хрома или Виндоус. Больше похоже на страшилку.
Очевидно, что вы не соприкасаетесь с фронтенд разработчиками. Вот сайт, на котором можно посмотреть поддержку веб стандартов, сафари занимает место ниже фаерфокса, про который так любят говорить, что он загибается. Некоторые баги сафари приходится решать на стороне бекенда, например с картинками webp, так как на стороне фронтенда никакими костылями их не исправить.
Желательно ещё увидеть что именно вы удаляете и как. Есть вероятность того, что удаляется метапакет, который нужен только для установки всего комплекта программ, удаление которого не поломает систему
Я не общался с разработчиком Pale Moon, но чтение комментариев на opennet или lor наталкивает на мысль, что некоторые люди испытывают чисто религиозный страх перед кодом фаерфокс, и не могут его принять.
Например, компактный режим решили скрыть, однако, кроме него есть ещё и интерфейс для сенсорных экранов. Это означает, что даже если код для компактного режима будет удалён, то сам механизм, за счёт которого он работал всё же останется в браузере, и вернуть его можно будет с помощью относительно маленького патча.
Соответственно, сопровождать такой код сможет даже небольшая команда, и при этом данный браузер всё равно будет гораздо более оптимизированным чем pale moon, который по сути является старым форком, преимущественно с патчами безопасности, и незначительными обновлениями.
К сожалению, их меньшинство. Те сайты, будь это как веб1.0 где злоупотребляют мелким шрифтом, так и современные где, лепят довольно большие полосы по бокам, и как только я перешёл с 768p на 1080p, то это стало очень заметно, при том, что диагональ не изменилась, и а вот площадь полезного контента уменьшилась.
Если просто оставить под каждым комментарием форму, то работать точно так же будет без js, хотя и будет занимать больше места на экране. Вопрос только в том, насколько сильно это сдвинет количество комментариев. То есть условно большинство браузерных движков станет тормозить не на 600 ответах, а на 800.
Кроме реализации на Ruby есть и другие языки со сборкой мусора: D, Go, Crystal и так далее. Там разницы в 25 раз нет. Кроме того, самые быстрые реализации на C++ имеют некоторые недостатки: либо это отсутствие части проверок корректности json, либо баги в реализации, либо определенные требования к железу и хранению данных, о чём сказано перед началом таблицы.
«Ошибок управления памятью всё же не совершают» — так вы хотите сказать, что это утверждение верно только для стандартной библиотеки?
Нет, это верно для кода, который полагается на сборку мусора, то есть того кода, который не вызывает free и вариации либо по той причине что не может — сам python, либо так как незачем — c.
Почему же Python multiprocessing не сохранил ссылку на передаваемый аргумент и позволил сборщику мусора забрать данные, которые нужны другому процессу?
Поскольку компилятор не проверяет код интерпретатора и библиотек на ошибки, а код достаточно нетривиален.
Форму ответа имхо можно создавать под комментом по нажатия кнопки «ответить» динамически
Да, верно, но это сделает js обязательным для работы сайта. Лично я поддерживаю подобный подход, но пользователи вроде ilammy или TCPpoPochte против этого. Кстати, это довольно хороший пример оптимизации с помощью js.
Вы говорите про multiprocessing, я говорю про NumPy.
Мой поинт был в том, что в Пайтоне хоть убейся, но не сможешь управлять памятью эффективно.
Кроме сборки мусора, между ними есть и другие различия, такие как типизация и интерпретация/компиляция. И если убрать эти различия, то преимущества ручного управления памятью либо уменьшаться, либо, в некоторых случаях исчезнут. Вот пример похожей задачи. Можно заметить, насколько сильно различаются даже задачи на одном языке, когда C++/g++ (Boost.PropertyTree) проигрывает как Ruby, так и другой реализации на C++. Как видите, некоторые реализации со сборкой мусора могут быть достаточно быстрыми.
Например, попробуйте запустить процесс через multiprocessing, передав ему в качестве аргумента NumPy массив, который освободится сразу после запуска процесса.
Это будет происходить в любых местах, когда управляют памятью несколько независимых систем.
И даже если обернуть RapidXML++ в Питон, то ничего это не изменит, потому что Питону всё равно для парсинга придётся создавать все эти маленькие строки-переменные, чтобы можно было сравнивать их значения с искомыми.
RapidXML++ использует свой менеджер памяти? Если строки только сравниваются на равенство, то можно обойтись без копирования, используя смещения.
В случае наличия MVC для фронта значительно падает количество дубликатов кода и логики написанной вручную, что позволяет реализовать тот же функционал быстрее, а следовательно — качественнее.
Gecko или Quantum? И ещё немаловажный аспект — даже если весь этот DOM будет создан на стороне сервера, то движки хрома, или старый фокс будут его плохо отображать, из-за его сложности. А значительно снизить сложность не получится, так как убрать формы ответа, ссылку на данный комментарий, родительский, голосование — не получится, разве что вводить разделение на страницы с ответами. Так что в этом вопросе js точно ни при чём.
Так можно метаться в любую сторону, не получая никакой выгоды.
стараются упростить формы
Нельзя упростить сразу всё — удобство использования, внешний вид, и так далее, так как упрощая одно усложняют другое. Меню только с одним пунктом в начале строки — это баг или фича? Или необходимость создания абзаца — это упрощение использования?
Например, компактный режим решили скрыть, однако, кроме него есть ещё и интерфейс для сенсорных экранов. Это означает, что даже если код для компактного режима будет удалён, то сам механизм, за счёт которого он работал всё же останется в браузере, и вернуть его можно будет с помощью относительно маленького патча.
Соответственно, сопровождать такой код сможет даже небольшая команда, и при этом данный браузер всё равно будет гораздо более оптимизированным чем pale moon, который по сути является старым форком, преимущественно с патчами безопасности, и незначительными обновлениями.
Поскольку компилятор не проверяет код интерпретатора и библиотек на ошибки, а код достаточно нетривиален.
Кроме сборки мусора, между ними есть и другие различия, такие как типизация и интерпретация/компиляция. И если убрать эти различия, то преимущества ручного управления памятью либо уменьшаться, либо, в некоторых случаях исчезнут. Вот пример похожей задачи. Можно заметить, насколько сильно различаются даже задачи на одном языке, когда C++/g++ (Boost.PropertyTree) проигрывает как Ruby, так и другой реализации на C++. Как видите, некоторые реализации со сборкой мусора могут быть достаточно быстрыми.
Вы говорите так, словно плюсы умеют работать с переменными, под которые не выделена память.
RapidXML++ использует свой менеджер памяти? Если строки только сравниваются на равенство, то можно обойтись без копирования, используя смещения.
Нельзя упростить сразу всё — удобство использования, внешний вид, и так далее, так как упрощая одно усложняют другое. Меню только с одним пунктом в начале строки — это баг или фича? Или необходимость создания абзаца — это упрощение использования?