2013-09-30 176 views
1

我一直在試圖弄清楚爲什麼我正在使用的用戶腳本在Firefox中很慢,但在Chrome和Safari中很火。我發現的一個原因(儘管可能不是唯一的原因)是userscript的大文件大小有很大的影響。腳本中有十本書的長度字符串,文件大小爲3.8 MB。如果我刪除字符串,腳本會再次變快 - 基本上,瀏覽器中的所有內容都會在文件加載時停下來(正好是用於典型用戶輸入交互的時間)。如何在腳本中壓縮/解壓縮字符串?

所以我想這可能有助於預壓縮字符串,然後在運行過程中根據需要進行解壓縮。任何人都有一個在一個用戶腳本內做到這一點的策略?

+0

字符串包含哪些數據? – Bergi

+0

敘述文本 – mix

+0

您的腳本始終處於開啓狀態嗎?問題實際上可能是那些首先存在的字符串;如果你馬上做,解壓縮到它們只會變慢。 – Ryan

回答

3

這裏有一些想法,所有未測試:從Greasemonkey的

  • 切換到Scriptish。腳本通常表現更好。

  • a)將文本拆分爲單獨的文本文件。
    b)將這些文件放置在您安裝腳本的位置。無需壓縮。
    c)用@resource directives指向每個文件;每個文件一個。
    d)在您的代碼中,使用GM_getResourceText()Doc可以在需要時獲取所需的文本。

  • 將文本分割成文件,將它們放在您自己的啓用了gzip的服務器(可能是本地計算機)上,並使用GM_xmlhttpRequest來按需獲取文件。
    服務器可以自動gzip文件,或者您可以預壓縮它們以節省幾毫秒。



至於存儲在您的userscript壓縮串;很難看出這將如何幫助業績。

壓縮文本可能會減少字節數,例如70%,但在腳本中不能使用二進制。你將不得不base64編碼它,你的腳本突然不再短了。

然後,你將不得不base64解碼,併爲每個使用unzip data using js。這兩種操作都會消耗JS中的時間和內存。
維護腳本和/或更改文本將會非常繁瑣。

似乎很多工作可能會帶來負面收益。

+0

scriptish的速度確實更快,可能足夠快速而沒有進一步修改。仍然沒有鉻/ safari快,但不是通用汽車公司的狗。是一個腳本語言,可以替代通用汽車,例如。像自動更新這樣的工作將以同樣的方式工作嗎?對於我之前的腳本,我在服務器上使用了一個scriptname.meta.js文件來通知GM有關更新的副本,從哪裏獲取它們等等。 – mix

+0

是的,除了可能存在一些'@ grant'行爲,所有FF GM腳本在Scriptish中的工作方式都是相同的。我沒有親自測試過Scriptish中的自動更新位,但我確定它沒關係。 Scriptish開發人員是Greasemonkey的長期貢獻者。 –