#performance #firefox #firefox-addon #greasemonkey
#Производительность #firefox #firefox-аддон #greasemonkey
Вопрос:
Я написал скрипт Greasemonkey, который выполняется на всех сайтах, проверяя некоторые вещи.
Поскольку она выполняется на каждой странице, производительность важна. Поэтому мне интересно, может ли надстройка Firefox быть быстрее.
Итак, это мои вопросы:
- Нужно ли Greasemonkey перезагружать скрипт при каждой (повторной) загрузке страницы?
- Может ли надстройка повысить производительность?
- Каковы преимущества, недостатки?
ОБНОВЛЕНИЕ:
некоторая справочная информация — я оцениваю задержку загрузки страницы в своем скрипте.
ОБНОВЛЕНИЕ 2 (дополнительная информация):
заголовок моего скрипта выглядит следующим образом:
// ==UserScript==
// @name My Script
// @namespace abc
// @description What it does
// @include *
// @resource moz_list http://mxr.mozilla.org/mozilla/source/netwerk/dns/src/effective_tld_names.dat?raw=1
// @resource resource_B http://mysite.org/res
// @version 1.0
// @grant GM_xmlhttpRequest
// @grant GM_getValue
// @grant GM_setValue
// @grant GM_getResourceText
// ==/UserScript==
Кроме того, я использую эти технологии:
- Типы данных словаря и массива
- Регулярное выражение для сопоставления ссылок
- tldextract код отсюда: https://github.com/masylum/tldextract
- JSON для хранения и извлечения словаря в кэше (могут ли stringify и eval быть быстрее?)
- document.getElementsByTagName()
- окно.Расположение.имя хоста
В псевдокоде моя основная функциональность выглядит следующим образом:
var host = window.location.hostname;
host = host.replace('www.', '');
if (host in my_dictionary) {
var links = document.getElementsByTagName('a');
for (i = 0; i < links.length; i ) {
if (host != links[i].hostname) {
if (links[i].href in my_dictionary[host]) {
do_some_stuff();
}
}
}
} else {
send_to_my_server(host);
}
Комментарии:
1. Вы всегда можете его протестировать. 😉 Не знаю, так ли это до сих пор, но однажды… Scriptish был быстрее, чем Greasemonkey, и примерно такой же, как надстройка. GM все еще далек от быстрого и эффективного. Если вы можете придумать способы кэширования или фонового процесса, используйте надстройку. В противном случае просто используйте скрипт GM / Scriptish. Простота разработки, обслуживания и развертывания / переносимости перевешивает незначительное снижение скорости.
2. Спасибо за подсказку для написания сценария. Звучит интересно. К сожалению, я попробовал это с помощью своего пользовательского скрипта, но это не сработало. И ничего особенного не используется. Недавно я запустил его с помощью tampermonkey, и я не хочу менять его на другой инструмент. Это действительно безумие, что пользовательские скрипты несовместимы между разными инструментами.
3. Ответ обновлен после обновления вопроса
Ответ №1:
После проблем с USO я также занялся аддонами, и мой опыт был:
Пользовательские скрипты:
- Только JavaScript
- Легко обновляется
- В основном не зависит от платформы / приложения (большинство пользовательских скриптов могут работать в Firefox, Chrome, Opera и т. Д., А также в Windows, Mac, Linux и т. Д. Без каких-Либо проблем)
- Запускается через другой аддон, который влияет на производительность
Надстройка Firefox:
- Более мощный с доступом к более эффективным встроенным API
- Требуется достаточное количество дальнейшего обучения
- Утверждение / проверка обновлений через официальный AMO происходят медленно (а иногда и мучительно медленно)
- Специфика приложения
В целом, если доступ к более мощным функциям (т.Е. Доступ к самому браузеру и его API) не требуется, пользовательские скрипты намного проще поддерживать, а небольшая потеря производительности в основном незначительна (я измерил ее, и разница в основном составляет несколько миллисекунд)
Обновление: после обновления 2 в исходном сообщении
GM_xmlhttpRequest, GM_getValue, GM_setValue amp; GM_getResourceText
Выше было бы более эффективно, если бы использовались собственные API (в зависимости от эффективности кода)
Словарные и массивные типы данных RegExp для сопоставления ссылок
Аналогичная производительность
tldextract код отсюда: https://github.com/masylum/tldextract
Лично я бы использовал свое собственное регулярное выражение в скрипте GM…но в Firefox () есть эффективный API Services.eTLD
, поэтому аддон будет более эффективным
JSON для хранения и извлечения словаря в кэше (могут ли stringify и eval быть быстрее?)
Аналогично для JSON …. eval()
следует избегать (я бы никогда не использовал eval)
document.getElementsByTagName()
Аналогичная производительность
окно.Расположение.имя хоста
Аналогичная производительность .. хотя в случае дополнений иногда (например, в импортированном JSM) требуется больше работы для получения окна и правильного
Общий комментарий:
Производительность кода часто может быть улучшена, даже в качестве скрипта GM. Например: document.links
более чем в два раза быстрее, чем document.getElementsByTagName('a')
Кэширование links.length
для повышения скорости и эффективности
for (var i = 0, len = links.length; i < len; i ) { }
Switch
часто быстрее, чем повторяется if ()
… вложенные if ()
иногда могут быть объединены и т. Д. и т. Д
Наконец, я бы предположил (хотя и предполагаю), что преобразование полностью оптимизированного скрипта GM в аддон может в лучшем случае повысить производительность на 10% (и требует много работы).
В то же время полная оптимизация скрипта GM может повысить производительность на 4-500% (или даже больше).
Удачи 🙂
Комментарии:
1. Я думаю, он ищет решение, которое показывает количественное улучшение производительности. Но это хороший ответ. Вы знаете, если мы увидим улучшение на 50% по сравнению с пользовательским скриптом?
2. Честно говоря, я не могу представить улучшение на 50% при аналогичном качестве кодирования (т.Е. Без кардинального изменения кода). Недавно я скомпилировал 6 своих пользовательских скриптов в 1 аддон, и улучшение производительности не было значительным. Важно то, что я ждал полного обзора другого дополнения с 30 мая, и теперь я № 42/170. Я также обновил 2 других дополнения на прошлой неделе, и обновления не будут доступны до проверки. Обновления скрипта обычно доступны немедленно.
3. Информативный ответ :), но Noitidart прав, я оцениваю задержку в своем пользовательском скрипте. Следовательно, производительность важна, и ускорение было бы отличным. Думаю, мне следовало указать на это более точно.
4. Разница в производительности СИЛЬНО зависит от кода. Если используются собственные API-интерфейсы Firefox, производительность повышается. Если код в основном имеет дело с DOM на странице, большой разницы не будет. Пример: запись в файл будет быстрее с использованием FF native API, по сравнению с передачей его в другое расширение для обработки. Производительность
getElementById()
была бы очень схожей в пользовательском скрипте и в аддоне. 🙂5. Хороший момент. В соответствии с этим, я думаю, что скорость не может быть увеличена. Что делает мой скрипт — посмотрите, есть ли домен в словаре, и если да, то измените DOM страницы с элементами, хранящимися в словаре. Если это не так, отправьте домен на мой веб-сервер. Далее словарь и список доменов, которых нет в dict, кэшируются. Так вы тоже считаете, что надстройка не может принести мне значительного ускорения? — Тогда я отмечу это как ответ.