Расширение Firefox: Производительность: Overlay vs Bootstrapped

Question

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

Было ли когда-нибудь сравнение производительности и ресурсов / памяти между наложенными и загружаемыми расширениями?

В расширениях наложения большая часть работы, например наложения XUL и т. Д., Обрабатывается приложением (т.е. Firefox). В загруженном расширении вся вышеуказанная работа оставлена ​​на усмотрение разработчика расширения, что часто включает ручное добавление множества слушателей событий и наблюдателей для достижения того же самого (что может быть не таким нативным, как ядро ​​приложения).

Я заметил беспомощные аддоны, которые иногда не запускаются в некоторых окнах. Я также заметил бесполезные дополнения, которые в некоторых случаях сама вставка была заметна (то есть функциональность, изображение, значок появляются немного после загрузки окна). Кроме того, тип используемого четного слушателя не является однородным и сильно варьируется.

У меня есть неприятное ощущение, что ручное (а не исходное) добавление меню, контекстных меню, функций, связок строк, предпочтений, локализации и т. Д. И перечисление окон будет использовать больше ресурсов (помимо того факта, что его эффективность будет в значительной степени зависеть от навыков разработчика),

С нетерпением жду ваших комментариев:)

Answer 1

То, как работает надстройка, в основном зависит от фактической реализации (что делает надстройка и как) и данных, которые она хранит. Таким образом, вы не можете просто сравнить производительность наложений и перезапуска надстроек.

Я преобразовал надстройки из оверлеев в перезапускаемые, которые потом работали лучше, потому что по пути я оптимизировал некоторые вещи. Конечно, в других случаях может быть и обратное.

Потребление памяти зависит от того, что делает надстройка, в т.ч. сколько слушателей событий это создает. Если вы не создадите тысячи за тысячами слушателей событий (которые также являются псевдо-утечками в замыканиях), память, используемая этими слушателями, обычно незначительна, как о: память скажет вам. Вы можете иметь надстройки с наложением памяти и легкие перезапускаемые надстройки или наоборот.

Вы правы, потому что эффективность во многом зависит от навыков, которыми обладает разработчик, то есть от качества реализации и структуры структуры данных, которая обычно напрямую связана с указанными навыками.

• Легко создать простую надстройку SDK "кнопка", но SDK имеет много и много абстракций, чтобы упростить ее, и эти абстракции потребляют ресурсы (память, процессор или даже файловый ввод / вывод).
• Немного сложнее создать эквивалентную надстройку наложения, но все же вы получаете довольно много вещей бесплатно (overlay, style). Эти тонкости также являются абстракциями более высокого уровня и стоят дорого.
• Довольно сложно создать эквивалентную надстройку с начальной загрузкой, но если все сделано правильно, она может превзойти другие типы надстроек, даже во время запуска (нет chrome.manifest для чтения, анализа и интерпретации, нет синхронизации загрузки оверлеев и связанных стилей, так далее.)

Это немного похоже на сравнение C (перезапуск) с Java (оверлей) с Ruby (SDK). Людям нравится удобство Ruby, но правильный Java-код легко превосходит его. С другой стороны, Java часто будет превосходить эквивалентные программы на C, написанные начинающими разработчиками (также эти начинающие разработчики, скорее всего, повредят память повсеместно;), но программа на C, написанная опытным разработчиком, может превзойти Java.

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

Как только вы заметите, что ваше дополнение потребляет тонны памяти или работает медленно, измерьте и / или устраните причину. Или просто измерить заранее. Дело в том: мера.

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

Поскольку вы спрашиваете о DOM-манипуляциях / оверлеях, addEventListener против "родной":

• Наложения могут быть быстрее, чем вызов набора методов DOM из JS. Но опять же, оверлеи - это XML, и их нужно читать с диска, затем анализировать в DOM, затем DOM необходимо объединить с наложенным DOM, следуя всем видам правил и т. Д. Для этого требуются все виды I/ I. O, (временная) память, процессор и т. Д. Поэтому наложение может быть медленнее. Зависит от наложения.
• addEventListener обычно невероятно быстро. На самом деле, оверлейные "события" слушателей, (те противные oncommand/onclick/onwhatever атрибуты), используйте одну и ту же реализацию внутренне (ну, вроде), и, кроме того, строковые значения из этих атрибутов будут все равно выброшены в движок JS путем создания анонимных функций из этих строк (и это тоже требует времени;)

В любом случае, в некоторых случаях я действительно измерял инициализацию пользовательского интерфейса в перезапускаемых надстройках (только DOM в JS), и всегда получалось что-то в (нижнем) двузначном диапазоне миллисекунд для любого надстройки с разумным количество DOM и слушателей (<100).

КСТАТИ:

Я также заметил бесполезные дополнения, которые в некоторых случаях сама вставка была заметна (то есть функциональность, изображение, значок появляются немного после загрузки окна).

Да, некоторые перезапускаемые надстройки, например, загрузка (кнопка панели инструментов) асинхронно или задержка (некоторая) их инициализации до более поздней точки (например, зачем заполнять контекстное меню раньше popupshowing?). Это может быть немного менее эффективно (потому что это может вызвать перерисовку) или может быть более эффективным (потому что браузер может продолжать выполнять другой код инициализации, в то время как изображения загружаются в фоновом режиме).

Если перезапускаемые надстройки не могут быть инициализированы, то это ошибка. Но я упомянул, что перезапускаемые надстройки уже довольно сложно написать.

PS: Gecko Profiler и about:memory твои друзья;)