Значительно ли дополнение 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==

Дополнительно использую следующие технологии:

  • Типы данных словаря и массива
  • RegExp для сопоставления ссылок
  • 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);
}

performance firefox firefox-addon greasemonkey
person Thorben    schedule 24.06.2014    source источник
comment
Всегда можно было проверить. ;) Не знаю, так ли это до сих пор, но когда-то... Scriptish был быстрее, чем Greasemonkey, и примерно такой же, как аддон. GM все еще далека от быстрой и эффективной. Если вы можете придумать способы кэширования или фонового процесса, используйте надстройку. В противном случае просто используйте скрипт GM/Scriptish. Эти простота разработки, обслуживания и развертывания / переносимости перевешивают незначительное снижение скорости.   -  person Brock Adams    schedule 24.06.2014
comment
Спасибо за подсказку Scriptish. Звучит интересно. К сожалению, я попробовал это со своим пользовательским скриптом, но это не сработало. И ничего особенного не используется. Недавно я начал работать с tampermonkey, и я не хочу менять его на другой инструмент. Это действительно безумие, что пользовательские скрипты несовместимы между разными инструментами.   -  person Thorben    schedule 24.06.2014
comment
Ответ обновлен после обновления вопроса   -  person erosman    schedule 25.06.2014

Ответы (1)


arrow_upward
5
arrow_downward

После проблем с USO я тоже занялся аддонами и мой опыт таков:

Пользовательские скрипты:

  • только JavaScript
  • Легко обновить
  • В основном не зависит от платформы/приложения (большинство пользовательских скриптов могут без проблем работать в Firefox, Chrome, Opera и т. д., а также в Windows, Mac, Linux и т. д.)
  • Запускается через другой аддон, который влияет на производительность

Дополнение Firefox:

  • Более мощный с доступом к более эффективным собственным API
  • Требуется изрядное количество дальнейшего обучения
  • Утверждение / проверка обновлений через официальный AMO выполняются медленно (а иногда и мучительно медленно)
  • Специальное приложение

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

Обновление: после обновления 2 в исходном сообщении.

GM_xmlhttpRequest, GM_getValue, GM_setValue и GM_getResourceText

Выше было бы более эффективно, если бы использовались собственные API (при условии эффективности кода)

Типы данных словаря и массива RegExp для сопоставления ссылок

Аналогичная производительность

tldextract код отсюда: https://github.com/masylum/tldextract

Лично я бы использовал свой собственный RegEx в скрипте 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% (или даже больше).

Удачи :)

person erosman    schedule 24.06.2014
comment
Я думаю, что он ищет решение, которое показывает количественное улучшение производительности. Но это хороший ответ. Вы знаете, увидим ли мы улучшение на 50% надстройки по сравнению с пользовательским скриптом? - person Noitidart; 24.06.2014
comment
Честно говоря, я не могу себе представить улучшение на 50% при аналогичном качестве кодирования (т.е. без кардинального изменения кода). Недавно я скомпилировал 6 своих пользовательских скриптов в 1 аддон, и улучшение производительности было незначительным. Что важно, так это то, что я ждал полного обзора на другой аддон с 30 мая, и теперь его нет. 42/170. Я также обновил 2 других дополнения на прошлой неделе, и обновления не будут доступны до тех пор, пока они не будут проверены. Обновления скрипта обычно доступны сразу. - person erosman; 24.06.2014
comment
Информативный ответ :), но Нойтидарт прав, я оцениваю задержку в своем пользовательском скрипте. Следовательно, производительность важна, и ускорение было бы здорово. Я думаю, что я должен был указать это более точно. - person Thorben; 24.06.2014
comment
Разница в производительности СИЛЬНО зависит от кода. Если используются собственные API Firefox, производительность повышается. Если код в основном имеет дело со страницей DOM, большой разницы не будет. Пример: запись в файл была бы быстрее с использованием собственного API FF по сравнению с передачей его другому расширению для обработки. Производительность getElementById() будет очень похожа в пользовательском скрипте и в аддоне. :) - person erosman; 24.06.2014
comment
Хорошая точка зрения. В соответствии с этим, я думаю, что скорость не может быть увеличена. Что делает мой скрипт - смотрит, есть ли домен в словаре, и если да, то модифицирует DOM страницы с элементами, хранящимися в словаре. Если это не так, то отправьте домен на мой веб-сервер. Далее кешируется словарь и список доменов, которых нет в dict. Так ты тоже считаешь, что аддон не может дать мне существенного ускорения? - Тогда я отмечу это как ответ. - person Thorben; 24.06.2014
comment
В конце концов так и будет, я думаю. Но на данный момент я не уверен, смогу ли я это уже опубликовать. Но я обновлю свой ответ командами и функциями Greasemonkey, которые я использую. - person Thorben; 24.06.2014