Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The first thing that comes to mind here is: how clever is the <a href="https://en.wikipedia.org/wiki/Web_browser_engine">rendering engine</a> you're using?</p> <p>That, generic as it sounds, matters a lot when questioning the efficiency of CSS rendering/selection. For instance, suppose the first rule in your CSS file is:</p> <pre><code>.class1 { /*make elements with "class1" look fancy*/ } </code></pre> <p>So when a very basic engine sees that (and since this is the first rule), it goes and looks at every element in your DOM, and checks for the existence of <code>class1</code> in each. Better engines probably map classnames to a list of DOM elements, and use something like a hashtable for efficient lookup.</p> <pre><code>.class1.class2 { /*make elements with both "class1" and "class2" look extra fancy*/ } </code></pre> <p>Our example "basic engine" would go and revisit each element in DOM looking for both classes. A cleverer engine will compare <code>n('class1')</code> and <code>n('class2')</code> where <code>n(str)</code> is number of elements in DOM with the class <code>str</code>, and takes whichever is minimum; suppose that's <code>class1</code>, then passes on all elements with <code>class1</code> looking for elements that have <code>class2</code> as well.</p> <p>In any case, modern engines are clever (way more clever than the discussed example above), and shiny new processors can do millions (tens of millions) of operations a second. It's quite unlikely that you have millions of elements in your DOM, so the worst-case performance for any selection (<code>O(n)</code>) won't be too bad anyhow.</p> <hr/> <p><h2>Update:</h2> To get some actual practical illustrative proof, I've decided to do some tests. First of all, to get an idea about how many DOM elements on average we can see in real-world applications, let's take a look at how many elements some popular sites' webpages have:</p> <p><strong>Facebook:</strong> ~1900 elements (tested on my personal main page).<br/> <strong>Google</strong>: ~340 elements (tested on the main page, no search results).<br/> <strong>Google:</strong> ~950 elements (tested on a search result page).<br/> <strong>Yahoo!</strong>: ~1400 elements (tested on the main page).<br/> <strong>Stackoverflow:</strong> ~680 elements (tested on a question page).<br/> <strong>AOL:</strong> ~1060 elements (tested on the main page).<br/> <strong>Wikipedia:</strong> ~6000 elements, 2420 of which aren't <code>spans</code> or <code>anchors</code> (Tested on the <a href="https://en.wikipedia.org/wiki/Glee_%28TV_series%29">Wikipedia article about Glee</a>).<br/> <strong>Twitter:</strong> ~270 elements (tested on the main page).</p> <p>Summing those up, we get an average of ~1500 elements. Now it's time to do some testing. For each test, I generated 1500 <code>divs</code> (nested within some other <code>divs</code> for some tests), each with appropriate attributes depending on the test.</p> <hr/> <h2>The tests</h2> <p>The styles and elements are all generated using PHP. I've uploaded the PHPs I used, and created an index, so that others can test locally: <a href="http://abody-pag.es/csstest/">little link</a>.</p> <hr/> <h2>Results:</h2> <p>Each test is performed 5 times on three browsers (the average time is reported): <strong>Firefox 15.0</strong> (A), <strong>Chrome 19.0.1084.1</strong> (B), <strong>Internet Explorer 8</strong> (C):</p> <pre><code> A B C 1500 class selectors (.classname) 35ms 100ms 35ms 1500 class selectors, more specific (div.classname) 36ms 110ms 37ms 1500 class selectors, even more specific (div div.classname) 40ms 115ms 40ms 1500 id selectors (#id) 35ms 99ms 35ms 1500 id selectors, more specific (div#id) 35ms 105ms 38ms 1500 id selectors, even more specific (div div#id) 40ms 110ms 39ms 1500 class selectors, with attribute (.class[title="ttl"]) 45ms 400ms 2000ms 1500 class selectors, more complex attribute (.class[title~="ttl"]) 45ms 1050ms 2200ms </code></pre> <hr/> <h2>Similar experiments:</h2> <p>Apparently other people have carried out similar experiments; this one has some useful statistics as well: <a href="http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/">little link</a>. <hr/> <h2>The bottom line:</h2> Unless you care about saving a few milliseconds when rendering (1ms = 0.001s), don't bother give this too much thought. On the other hand, it's good practice to avoid using complex selectors to select large subsets of elements, as that can make some noticeable difference (as we can see from the test results above). All common CSS selectors are reasonably fast in modern browsers. </p> <p>Suppose you're building a chat page, and you want to style all the messages. You know that each message is in a <code>div</code> which has a <code>title</code> and is nested within a <code>div</code> with a class <code>.chatpage</code>. It is <strong>correct</strong> to use <code>.chatpage div[title]</code> to select the messages, but it's also bad practice efficiency-wise. It's simpler, more maintainable, and more efficient to give all the messages a class and select them using that class.</p> <hr/> <h2>The fancy one-liner conclusion:</h2> <p>Anything within the limits of "yeah, this CSS makes sense" is <em>okay</em>.</p>
    singulars
    1. This table or related slice is empty.
    1. POWhich CSS selectors or rules can significantly affect front-end layout / rendering performance in the real world?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USChris
    1. USChris
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhich CSS selectors or rules can significantly affect front-end layout / rendering performance in the real world?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI'm afraid I was hoping for a more in-depth answer than this (I'll probably add a bounty when I can in a couple of days if I haven't got a great answer). Obviously it depends on the rendering engine, but I'm unsurprisingly particularly interested in how recent versions of Webkit (Chrome / Safari), Gecko (Firefox) and Trident (IE) (and to a lesser extent, Presto) perform. And as to your general point that rendering performance doesn't matter, are you sure that applies to complex CSS3 queries, like the regular-expression-like ones mentioned in my question?
      singulars
      1. PO
      1. USRobin Winslow
    2. CO@RobinWinslow It's not that it *doesn't matter*; you just can't optimize it much by changing minor stuff (like 'avoiding IDs'). Regular expressions aren't as evil as you're connoting -- again, don't forget you're dealing with strings that are almost never more than 10 characters long. **On the other hand**, avoiding using more complex selectors when you can gives you: **A)** a cleaner CSS file. **B)** a boost in performance. If IDs did suck as much as some articles are claiming, the CSS specification wouldn't have included them.
      singulars
      1. PO
      1. USChris
    3. CO@Abody I really don't want to discuss the "should you use IDs" thing 'cos it's off-topic, but you can't surely be suggesting that the CSS spec was flawless? In response to **A)** yes it makes CSS cleaner (which is good), but once again I'm *specifically* asking about performance effects. I'd still welcome some concrete examples of people actually measuring rendering performance.
      singulars
      1. PO
      1. USRobin Winslow
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload