[Edbrowse-dev] deminimization and performance

[Edbrowse-dev] deminimization and performance

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]

A new demin command toggles the deminimizing of javascript.
This is only for debugging; a typical user should never do this.
javascript from a file (rather than inline in the html) is deminimized if the average line length exceeds 1000, whence it was probably minimized.
We don't want to deminimize regular source, that just makes it worse.

But there are some serious performance considerations.

nasa.gove takes 1 minute 30 to browse, which is already unacceptably slow.
With demin on it takes 3 minutes, an extra 90 seconds just to do the deminimization. Ouch!
Well we're the only ones doing it, and only to debug, so I guess that's ok.

A bigger problem is the edbrowse footprint.
The executable is now 1.1 meg, and 2/3 of that is the javascript string.
Lordy, it's just an ascii string!
If it were compressed by a typical program, we'd save nearly half a meg on the edbrowse executable.
I don't care whether zip or gzip or bzip2 or whatever, but we need a shared library to unzip the string
at run time and then feed it to duktape.
The library has to be common to linux, bsd, mac, and windows (Geoff).
Any ideas? Anyone want to take this on?
It's not a high priority, but I think we should do it before we cut another version with all this glop in the js files.

These monster functions are compiled and stored in every frame and every window.
I thought about this inefficiency before, just with our stuff.
document.getElementsByTagName() is a static function,
no need to repeat it window by window by window.
Compile it in the master window, then every other window says
document.getElementsByTagName = master.document.getElementsByTagName;
There is already a master window that you don't see, which is necessary for duktape to run properly.
So I had given some thought on how to do this, and I think it's feasible, but now it's much more important.
These monster functions, almost all of third.js, should only be compiled in the master window, then every other window can simply reference them.
That could make a big difference if you sit in edbrowse all day and open all sorts of windows and buffers etc.

Karl Dahlke