edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
* [Edbrowse-dev] eb$master
@ 2017-09-19  5:52 Karl Dahlke
  2017-09-19  8:16 ` Kevin Carhart
  0 siblings, 1 reply; 2+ messages in thread
From: Karl Dahlke @ 2017-09-19  5:52 UTC (permalink / raw)
  To: Edbrowse-dev

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

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Edbrowse-dev] eb$master
  2017-09-19  5:52 [Edbrowse-dev] eb$master Karl Dahlke
@ 2017-09-19  8:16 ` Kevin Carhart
  0 siblings, 0 replies; 2+ messages in thread
From: Kevin Carhart @ 2017-09-19  8:16 UTC (permalink / raw)
  To: Karl Dahlke; +Cc: Edbrowse-dev



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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-09-19  8:14 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-19  5:52 [Edbrowse-dev] eb$master Karl Dahlke
2017-09-19  8:16 ` Kevin Carhart

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).