On Sun, Feb 11, 2018 at 07:25:31PM +0000, Adam Thompson wrote: > On Sun, Feb 11, 2018 at 01:53:51PM -0500, Karl Dahlke wrote: > > The css portion, that maps css attributes over to objects, takes 2 minutes > > to run. > > That's not the infinite loop, but it is intolerable nonetheless. > > Browse www.stackoverflow.com with db3 and watch 2 minutes go by between > > > > execute eb$qs$start > > execution complete > > Wow, yeah... that's not good. > > > The version we got was built to run and handle all situations, and be > > robust, but obviously not optimized. > > Optimizing things is something I'm good at, but it's a lot of code doing > > something I'm not entirely familiar with, so I would be taking a big bite. > > Could it be optimized and still be javascript? Is it primarily an > > algorithmic inefficiency? > > Or would it have to be rewritten in C? > > I hope the former, because turning all that into C would be a pain! > > There's no real reason to mess with the css parser, that runs once and > > pretty fast, > > but querySelectorAll compares every css directive against every node in the > > document, which is potentially an n^2 problem. > > Yeah, that sounds like an algorithm problem, I'll take a look and see if > there's anything obvious. > May be there's some way to ignore certain directives, I'm not entirely sure > yet. > > Thanks for looking at this.
Ok, just had a quick look through the code, and my js is... not great... but I wonder if we could (may be lazily when we first traverse looking for selectors) hash element references based on selectors. That *should* save traversals in subsequent calls to querySelectorAll. That being said, I'm not entirely sure I can understand how that code does its job so I may be missing something important there. Cheers, Adam. _______________________________________________ Edbrowse-dev mailing list Edbrowse-dev@lists.the-brannons.com http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
