[Edbrowse-dev] jspool

[Edbrowse-dev] jspool

[Karl Dahlke]

People doing lots of browsing, on new machines, will want a large js pool;
people with older low memory machines that mostly edit files
will not want to waste that memory on js, and will want a smaller pool.
I can make a new config parameter for this if you agree.

Karl Dahlke

Re: [Edbrowse-dev] jspool

[Chris Brannon]

> I can make a new config parameter for this if you agree.

Yes, that sounds like the way to go.

-- Chris

Re: [Edbrowse-dev] jspool

[Kevin Carhart]

Is this a good time to have a thread about the more specific end of 
things, or is there still so much going on with the basic architecture 
that it's premature?

I have built the latest a few times and pulled up acid3.acidtests.org.
There are a bunch of things we could talk about.  In order to take it from 
the top, I tried test #0.  (The tests are numbered 1 to 100, but there is 
also a zero.)  Test #0 actually does not use the iframes, but it does use 
CSS selectors.  So we could discuss #0, or leap ahead to one of the tests 
that uses the new iframe support but still doesn't pass, or wait a while.

Kevin


  On Sun, 13 Aug 2017, Karl Dahlke wrote:

> I think we have a good foundation now - so over the next couple months I hope we can get a lot more sites working, either by plowing through acid tests methodically, or fixing individual sites that people want.
>
> Karl Dahlke
>

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

Re: [Edbrowse-dev] jspool

[Kevin Carhart]

> duktape doesn't have a pool of a fixed size, it allocates what it needs. Duh!

This is great!  Occasionally I will hit the message about cannot allocate 
more memory.  And I also think that ability to allocate memory dynamically 
could be another test that site-makers put the client through in order to 
call the bluff of user-agent spoofers, in addition to things like styles 
and testing the decimal places on numbers.

[Edbrowse-dev] jspool

[Karl Dahlke]

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

You know what's funny? I finally got rid of the old jspool parameter.
Remember we had to set the size of the js pool at startup?
We had to anticipate, guess, how much space edbrowse would need for js, and if we were in edbrowse all day and browsed yet one more site with lots of js, boom!
Well we don't have to worry about that any more.
duktape doesn't have a pool of a fixed size, it allocates what it needs. Duh!
So jspool is a nice thing to leave behind.

I left the memory hog test in jsrt for now.
Push the memorry fill button and it creates 20 million objects no problem.
Although, ha ha, it prints a counter every 10,000 objects, which is fine for me, but my wife finally told me that alert on any other browser is not the same as print,
it's a message that you have to acknowledge before you can move on.
Sometimes I'm at a real disadvantage never running a regular browser.
Nobody would want to click ok 200 times, so maybe I should remove that status alert.
Well nobody runs jsrt on a regular browser, except Geoff, cause he's curious.

Karl Dahlke