edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
* [Edbrowse-dev] nasa slow
@ 2018-02-10 11:51 Karl Dahlke
  2018-02-11  5:04 ` Kevin Carhart
  0 siblings, 1 reply; 5+ messages in thread
From: Karl Dahlke @ 2018-02-10 11:51 UTC (permalink / raw)
  To: Edbrowse-dev

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

Using my local instance of nasa.gov, so I don't have to keep crawling on the internet,
I find the output is the same with or without several js files, and with or without the two css files, but,
without css the page browses in 6 seconds, with css it takes a minute 10.
Frustrating, since 99% of the time we don't need css anyways, but if we ever need it then I guess we have to do it.
There's an initial 6 seconds setting up css on the web page, I can live with that I guess, but all the rest comes from calls to getComputed Style().
I print g at the start of that routine, and h at the end, and almost all the time is spent between g and h.
Worse still, I'm using third party software that I don't want to mess with.
Yet I might have to, at some level, because we can't live with this much inefficiency.
querySelectorAll is running through the entire document tree, evaluating each node against each css selector, when it only has to examine one node in particular, the one passed to getComputedStyle.
But the traversal seems implicit to the third party software.
I can't tell it to look at just one node.
I'm not sure what to do here.

Karl Dahlke

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

* Re: [Edbrowse-dev] nasa slow
  2018-02-10 11:51 [Edbrowse-dev] nasa slow Karl Dahlke
@ 2018-02-11  5:04 ` Kevin Carhart
  2018-02-11  6:31   ` Karl Dahlke
  0 siblings, 1 reply; 5+ messages in thread
From: Kevin Carhart @ 2018-02-11  5:04 UTC (permalink / raw)
  To: Karl Dahlke; +Cc: Edbrowse-dev



> without css the page browses in 6 seconds, with css it takes a minute 10.

Thank you for finding this out.  So jotform and the other 
third.js code is the culprit.  I know we are facing potentially a
user-alienating outcome if we keep it and a different user-alienating 
outcome if we ditch it.

> Frustrating, since 99% of the time we don't need css anyways, but if we ever need it then I guess we have to do it.

I'm not so sure.. a lot of the big sites will be making heavy use of the 
styles as de facto discernment of the UA.  I know that the other 
alternative is no good either, if we use the third.js libraries but the 
result is unacceptably slow.  It's possible that both doing it and not 
doing it both have big problems.  But I think that the CSS question as a 
whole is somewhat more integral than only 1% of the time.  NASA needs it 
in order to run, right?  So if NASA is your proxy for the average state of 
things, a lot of other sites will too.

I have some things I should get in and haven't gotten in, like the issue 
within "my" section, the XHR code.  I'm going to try to send a startwindow 
soon.  Thanks for the new debugging commands.

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

* [Edbrowse-dev] nasa slow
  2018-02-11  5:04 ` Kevin Carhart
@ 2018-02-11  6:31   ` Karl Dahlke
  2018-02-11  7:00     ` Kevin Carhart
  0 siblings, 1 reply; 5+ messages in thread
From: Karl Dahlke @ 2018-02-11  6:31 UTC (permalink / raw)
  To: Edbrowse-dev

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

> NASA needs it in order to run, right?

No, they don't, and that's the point. It's just a big time waster from our point of view.
Acid test 0 needs it, and that's what put us on the trail, remember, but I think that's rare.
(At some point we might return to the acid tests as well, we can do both, real world sites and acid tests, but you see how acid could lead us astray, exercising things that just aren't used, or not very often.)

However, I found a way to improve it mightily, still with all the css functionality intact, and down from 1m10 to 20 seconds.
I think it's kinda clever, see the last push.
It will be hard to optimize this area further, without mucking seriously  with the third party software,
which I don't want to do, so we can just snap in the next version, with bug fixes enhancements etc, when it comes.

Karl Dahlke

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

* Re: [Edbrowse-dev] nasa slow
  2018-02-11  6:31   ` Karl Dahlke
@ 2018-02-11  7:00     ` Kevin Carhart
  2018-02-11 16:50       ` Adam Thompson
  0 siblings, 1 reply; 5+ messages in thread
From: Kevin Carhart @ 2018-02-11  7:00 UTC (permalink / raw)
  To: Edbrowse-dev

On Sun, 11 Feb 2018, Karl Dahlke wrote:

>> NASA needs it in order to run, right?
>
> No, they don't, and that's the point. It's just a big time waster from our point of view.
> Acid test 0 needs it, and that's what put us on the trail, remember, but I think that's rare.

Hmmmm

But querySelector and querySelectorAll are used in vendor.js or nasa.js, 
right?  These are common.

So we have a couple of things in third.  It sounds like we're saved by the 
bell for now since you figured out how to do both, which is great, but 
maybe some time in the future if it was necessary, we could delete jotform 
but keep qs/qsa?

But come to think of it... wouldn't the query-result sets from qsa be 
incomplete if the styles have not been doled out to the elements 
previously and the selector is trying to select by styles?


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

* Re: [Edbrowse-dev] nasa slow
  2018-02-11  7:00     ` Kevin Carhart
@ 2018-02-11 16:50       ` Adam Thompson
  0 siblings, 0 replies; 5+ messages in thread
From: Adam Thompson @ 2018-02-11 16:50 UTC (permalink / raw)
  To: Kevin Carhart; +Cc: Edbrowse-dev

On Sat, Feb 10, 2018 at 11:00:44PM -0800, Kevin Carhart wrote:
> On Sun, 11 Feb 2018, Karl Dahlke wrote:
> 
> > > NASA needs it in order to run, right?
> > 
> > No, they don't, and that's the point. It's just a big time waster from our point of view.
> > Acid test 0 needs it, and that's what put us on the trail, remember, but I think that's rare.
> 
> Hmmmm
> 
> But querySelector and querySelectorAll are used in vendor.js or nasa.js,
> right?  These are common.
> 
> So we have a couple of things in third.  It sounds like we're saved by the
> bell for now since you figured out how to do both, which is great, but maybe
> some time in the future if it was necessary, we could delete jotform but
> keep qs/qsa?
> 
> But come to think of it... wouldn't the query-result sets from qsa be
> incomplete if the styles have not been doled out to the elements previously
> and the selector is trying to select by styles?

Yes they would, and worse than that it'd be difficult to spot because there's a good chance things'd
either continue in a broken state or blow up with some sort of type error.
I'm thinking that we'll just have to fix the 3rd party software if it isn't good enough.  Have we contacted
the devs about it to see if they intend to fix it?

Cheers,
Adam.
PS: in order to do almost anything in edbrowse I have to browse with js disabled until I find a broken
site because it's so grindingly slow most of the time, and that's on relatively modern hardware, but
may be that's just the sites I visit... plus there's the js either being horribly inefficient or infinite
on (I think) stackoverflow.com etc which is a real problem (I seem to manually kill edbrowse at least twice
a day at work).  I really should sit down and debug what's going on there.

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

end of thread, other threads:[~2018-02-11 16:49 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-10 11:51 [Edbrowse-dev] nasa slow Karl Dahlke
2018-02-11  5:04 ` Kevin Carhart
2018-02-11  6:31   ` Karl Dahlke
2018-02-11  7:00     ` Kevin Carhart
2018-02-11 16:50       ` Adam Thompson

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