Добавката за 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()
  • window.location.hostname

В псевдокод основната ми функционалност е следната:

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 скрипт ... но има ефективен API във Firefox (Services.eTLD), така че Addon ще бъде по-ефективен

JSON за съхраняване и извличане на речника в кеша (може ли stringify и eval да бъдат по-бързи?)

Подобно за JSON .... eval() трябва да се избягва (никога не бих използвал eval)

document.getElementsByTagName()

Подобно изпълнение

window.location.hostname

Подобна производителност ..въпреки че в случай на добавки, понякога (като в импортирания 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
Информативен отговор :), но Noitidart е прав, правя оценка на латентността на моя потребителски скрипт. Следователно производителността е важна и ускоряването би било чудесно. Предполагам, че трябваше да го посоча по-точно. - 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