edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Karl Dahlke <eklhad@comcast.net>
To: Edbrowse-dev@lists.the-brannons.com
Subject: [Edbrowse-dev] deminimization and performance
Date: Mon, 18 Sep 2017 22:01:52 -0400	[thread overview]
Message-ID: <20170818220152.eklhad@comcast.net> (raw)

[-- 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

                 reply	other threads:[~2017-09-19  2:00 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170818220152.eklhad@comcast.net \
    --to=eklhad@comcast.net \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).