You'd have better luck asking for this feature in https://discourse.wicg.io. ES Discuss is about the JS language itself and the related ECMAScript spec, not the Web APIs that are implemented in most browsers, usually separately to the JS implementations themselves.
----- Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com On Thu, May 23, 2019 at 10:05 AM Randy Buchholz <w...@randybuchholz.com> wrote: > > Full Table Scans and Unique indexes are database concepts (that's the DBA > reference). When a database searches for a record based on a column value, it > might look at every record in the table to find the matches - scan the entire > (full) table, in the order the records were inserted or stored. To speed this > up, we can create indexes on table columns or column groups. These are like > ordered maps or hash tables. To find a record, more efficient searches can be > done against the indexes to find the records. Indexes can also act as > constraints. A "Unique Index" is a constraint that checks a table to see if a > value exists before inserting it in the table and adding it to the index. > Indexing has a trade-off. It slows inserting, but improves searching. While > understanding that databases and browsers are worlds apart, a foundational > part of database engines is searching, just like it is in DOM manipulation. > Indexing can provide orders of magnitude performance improvements when > reading/search in > g in databases. It seemed worth seeing if the concept translated across > technologies. > > Without any optimizations, an attribute search on a document would look at > each node, and then at each attribute of the node to find a match - Full > Table Scan. This makes searches very slow. At an absurd extreme, we could > index everything, making startup very slow and eating memory, but making some > searches very fast. The balanced approach is to implement "indexing" > ourselves (using any of the mentioned approaches) to get the best level. > > About the code/HTML, it is dynamic and real-time. It is loaded over > WebSockets, and the elements are talking to the backend in real-time over the > sockets. I'm using an original (Trygve Reenskaug) MVC approach. Essentially, > each Web Component is an MVC component, with the HTML/elements and code > accessed only through the controller. I am looking at the incoming code for > cases where several searches ae being performed on the same attribute (or > element). I give these a generated `id`, create indexes on them, and expose > them as properties on the controller. The underlying framework uses a set of > common attributes that are searched on a lot, but only for a small set of > elements. These are also indexed. So at the cost of slower startup (offset to > some degree by doing some of this in a Web Worker and/or server-side), I can > read and write "Form Fields" quickly. > > Many language features are implemented to wrap or optimize common or > repetitive use cases, or to move code to a more efficient part of the > architecture. Indexing can do both. Without doing things server-side or in > Workers, the indexing consumes UI cycles. Adding an indexing "hint" could > allow all or part of this code to be moved back into the "system" or C++ > layer. (e.g., into `querySelect` internals supported by low-level map stores) > Or to parsing (like I'm doing), taking some of the repetitive work off the UI > and developers hands. > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
