Re: [Edbrowse-dev] eb$master

[Kevin Carhart <kevin@carhart.net>]

Thank you for doing this, I'm glad you have an idea of what to do.  I'm 
also worried about the underlying speed issue:

> nasa.gove takes 1 minute 30 to browse, which is already unacceptably 
> slow.

Do you know where the bulk of the delay lies?  I thought maybe it was 
related to the CSS.  Doling out styles to elements, maybe inefficiently, 
like a cartesian product.  But I am actually not sure.

Is it fair to say that the slow pages like nasa.gov are not a regression, 
but we now have slow things that weren't supported at all, previously?  Is 
there a danger of leaving anyone worse off?

> showscripts

These new utilities are very exciting.  Also, til today I had never run 
the standalone duk even though you had mentioned it.  I had only compiled 
the library thus far.  The standalone duk is very useful in conjunction 
with demin, because standalone duk gives you a stack trace for errors, 
with a line number for every call!  If good line numbers are available you 
get very rich information.  I had no idea we could find this out.. it's a 
new world, at least for find & fix!




On Tue, 19 Sep 2017, Karl Dahlke wrote:

> As per my last post, I now give each window access to the master window through eb$master.
> This window is always there, behind the scenes.
> Even if you unbrowse every file, so it looks like there is no js anywhere in edbrowse, the master window persists.
> If functions have been compiled in the master window then eb$master.compiled will be true.
> We can, in *.js, test for this, and if it is false we can compile a large static function in the master window,
> then link to it from our window.
> I have done this for dumptree(), showscripts(), and the console object.
> These functions are compiled once but available from every window.
> If things don't blow up I'll do the same for most of the other functions,
> especially the monster functions in third.js.
> This makes it a little less cut&paste to put in an updated snapshot of one of these functions however.
> If it says function foo() we have to change that to eb$master.foo = function()
> but other than that it isn't hard, just something we maintainers have to remember to do.
> Check it out, and if you don't object I will gradually transform the other static functions into a compile-once mode.
> I don't bother doing this for the little one or two line functions,
> and certainly no point for the native methods, since a pointer to C takes up less space than a pointer to eb$master.whatever.
>
> Karl Dahlke
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists