1

I've been trying to figure out why a userscript I'm working on is slow in Firefox yet blazing in Chrome and Safari. One reason I've identified (though maybe not the only reason) is that the large file size of the userscript is having a big effect. The script has ten book length strings in it, for a file size of 3.8 MB. If I remove the strings the script gets fast again---basically everything in the browser grinds to a halt while the file loads (right at the time for a typical user input interaction).

So I was thinking it might help to precompress the strings, then uncompress as needed during the run. Anyone have a strategy for doing this within a userscript?

mix
  • 6,943
  • 15
  • 61
  • 90
  • What data do the strings contain? – Bergi Sep 30 '13 at 15:55
  • Is your userscript always on? The problem is probably actually those strings existing in the first place; decompressing to them will just be slower if you do it right away. – Ry- Sep 30 '13 at 16:01
  • the script won't use all of those strings in a run---only one of the 10---so 90% of them could stay compressed. as for always on, it's a script that adds text to a gmail compose window, so it loads when that window loads (more than once actually). – mix Sep 30 '13 at 16:06

1 Answers1

3

Here are some ideas, all untested:

  • Switch from Greasemonkey to Scriptish. Scriptish generally performs better.

  • a) Split the texts into separate text files.
    b) Place these files where you install your script from. No need to compress.
    c) Point to each file with @resource directives; one for each file.
    d) In your code, use GM_getResourceText()Doc to get just the text you want, when you want it.

  • Split the text out into files, host them on your own gzip-enabled server (could be your local machine) and use GM_xmlhttpRequest to fetch the files on demand.
    The server could automatically gzip the files, or you could pre-compress them to save a few milliseconds.

As for storing compressed strings in your userscript; it is difficult to see how this would help performance.

Zipping your text might reduce the number of bytes by, say, 70%, but you can't have binary in a userscript. You would have to base64 encode it, and your script suddenly isn't much shorter anymore.

Then you would have to both base64 decode it, and unzip data using js for each use. Both of these operations will chew up time and memory in JS.
Maintaining the script and/or changing the text will be quite a bit more tedious.

Seems like a lot of work for possibly negative gain.

Community
  • 1
  • 1
Brock Adams
  • 90,639
  • 22
  • 233
  • 295
  • scriptish is indeed faster, perhaps fast enough w/o making further modifications. still not as fast as chrome/safari but not the dog that GM is. is scriptish a drop-in replacement for GM---e.g. will things like auto-updating work the same way? for my previous scripts, i used a scriptname.meta.js file on the server to inform GM copies about updates, where to get them, etc. – mix Sep 30 '13 at 23:19
  • Yes, except for possibly some `@grant` behaviors, all FF GM scripts will work the same way in Scriptish. I haven't personally tested the auto-updating bit in Scriptish, but I'm sure it's okay. The Scriptish dev is a long-time contributor to Greasemonkey. – Brock Adams Sep 30 '13 at 23:45