Performance inquiry

[jasonkarns]

I'm curious what the current state of browsers is, with regards to attribute-based selectors. For quite a while, attribute selectors were nearly an order magnitude slower in IE. But I'm no longer aware if that's the case.

Has there been any research or benchmarks done to see what performance would be across the current browser landscape using this attribute-based approach? (Keeping in mind that selector speed is not limited to CSS since most client-side-heavy apps will be making heavy use of selectors for the JS component of the app itself.)

[benschwarz]

Our initial research showed that "poor" attribute selector performance in actual practice, is somewhat of a misnomer.

Its been the most asked thing since we announced AM yesterday, so we're going to spend some time putting together some benchmarks that will bring data to the table.

[maciej-gurban]

I can't vouch for the methodology of these, but take a look at: http://jsperf.com/custom-attribute-selector-speed http://benfrain.com/selector-test/03.html But also: http://calendar.perfplanet.com/2011/css-selector-performance-has-changed-for-the-better/

[lmartins]

This was the first question that popped into my mind when I first learn of AMCSS. Love the idea, suspect that the difference will be marginal for most sites, still curious to know more about it.

[yuvii]

Why build an entire system around the idea of terribly inefficient selectors? It's true that things have changed a lot. When writing CSS you don't need to think about performance usually.

But still, there's a big difference between "not spending too much time on writing efficienctly" to "building an entire framework around inefficiency", don't you think?

I'm eager to see the results of the benchmarks, but I have to say I'm very skeptical about this whole thing

[RyanRoberts]

@yuvii

@maciej-gurban posted some links above, the performance difference is almost irrelevant. I guess it may have an impact on very large very complex sites, but maybe not.

[yuvii]

@RyanRoberts

I guess it may have an impact on very large very complex sites

Which are... exactly the kind of sites that amcss is supposedly good for, right? Because you don't need this level of decomposition for styling on small-scale sites. So small sites don't have anything to benefit from this and large sites will suffer from bad performance. amcss seems like a very bad idea to me.

[maciej-gurban]

I think you guys could some research before spreading this method. It looks neat and in some cases clears up the code, but building a grid, and other complex and often repeating elements with it could have bigger overhead you'd expect. But then again, we're only speculating at this point. An in order to cut that speculation, you need quality research and tests.

The links I provided are far from a source trust-worthy enough for me even attempt using amcss in production. Additionally, they state contradictory things. On one hand, you have an article stating that the performance has improved and benfrain.com test that doesn't show much disproportion between single class selector and attribute-based selectors. But there's also the jsperf test showing a staggering difference in performance between the two when querying DOM.

Edit: I see you already started :D Edit2: Corrected a confusing part, as pointed out by @bensmithett https://github.com/amcss/am-benchmarks

[bensmithett]

@maciej-gurban the jsperf link is testing DOM querying rather than CSS selector matching (are the two related under the hood?)

[maciej-gurban]

@bensmithett You are correct, they are two different things and I made them sound to be the same. I assume for most of us it's the CSS selector matching that's the priority here - which seems not so bad. However since amcss aims to become a production-ready solution, DOM querying speed should be taken into account as well.

[geelen]

Yep, we're working on it. The problem is nobody has a rock-solid methodology for determining the impact of 'slow' vs 'fast' selectors in the real world. Yes, attribute selectors will be slower, but we don't know by how much, and we definitely don't know how much that will contribute to the load time for your use-case.

So, in the words of Jim Barksdale:

If we have data, let’s look at data. If all we have are opinions, let’s go with mine.

My opinion is that, for my own CSS, I've seen a huge increase in clarity & maintainability of markup since switching to AM, and literally no perceptible performance impact. YMMV.

[eltonmesquita]

I do agree with you @geelen. But as we don't have a rock solid method, why not use edge cases? Like, two pages, one simple with little weight and other pretty heavy and "hard for a browser to deal with" and test them in many real world devices. Then it was just a matter of gathering this data and compare...

As laborious as it might look, it wouldn't be a big problem as I'm sure anyone that wishes to use AM will test it in many devices they can get and probably share the results. This way we would have a kinda of reliable measurement and have a proof it's ok to use AM.

[yuvii]

@eltonmesquita Except no, that's not an edge case. Small examples won't reflect anything because the performance will be miniscule and irrelevant. Even more so considering small projects don't need to use am at all.

It's only large projects that will show performance issues. And here's the kicker - am is only relevant for large scale websites. Its speculative, but still probable.

So we only need a benchmark for a very large site and prove that these selectors aren't costly - only then will am be a reasonable production-friendly solution

[ConnorKrammer]

That's a little tricky though, since ideally you'd implement the same site using class selectors and attribute selectors and then test the difference. In practice, it's almost impossible to do this without introducing other sources of error.

Then again, maybe someone more experienced with performance tests can think up a relatively unbiased method.

[geelen]

I think you might be missing the point of AM. AM is about information being better captured by two variables instead of one. It's just as relevant for small websites. Big sites start small, and implementing a structure early on helps maintainability in the long run. But that's off topic for this issue. Feel free to raise another if you'd like to continue to discuss that point.

Besides, as @benschwarz already pointed out, selector performance is related to number of elements in the DOM, not number of selectors. There are plenty of flat-out huge websites that have massive amounts of CSS, for which BEM and AM are going to be hugely beneficial, that have relatively moderate numbers of selectors.

I want to steer clear of anecdotal performance tests, "hard data" means rigorous data. I hope to have some by tomorrow, depending on how pro my node hax are in my hotel room tonight. Top Gun soundtrack will be deployed.

On Monday, September 8, 2014, Yuval Bar-On notifications@github.com wrote:

@eltonmesquita https://github.com/eltonmesquita Except no, that's not an edge case. Small examples won't reflect anything because the performance will be miniscule and irrelevant. Even more so considering small projects don't need to use am at all.

It's only large projects that will show performance issues. And here's the kicker - am is only relevant for large scale websites. Its speculative, but still probable.

So we only need a benchmark for a very large site and prove that these selectors aren't costly - only then will am be a reasonable production-friendly solution

— Reply to this email directly or view it on GitHub https://github.com/amcss/attribute-module-specification/issues/7#issuecomment-54837170 .

[ConnorKrammer]

@geelen bringing out the heavy artillery, I see.

[geelen]

Updated https://github.com/amcss/am-benchmarks with a readme about the status of my investigation.

The TL;DR is that I'm proxying/reproducing arbitrary sites, converting <div class="foo"> into either <div am-foo> or <div am-klass="foo">, and rewriting the CSS on the fly. For example:

• http://am-benchmark.glenmaddern.com/classes/http://getbootstrap.com
• http://am-benchmark.glenmaddern.com/attributes/http://getbootstrap.com
• http://am-benchmark.glenmaddern.com/values/http://getbootstrap.com

So go run this on your own site! See how your newly (and dumbly) AM-ified site performs!

We're pretty close to having hard data now, just need a reliable test harness that can fire up 100 or so runs on each of these and get good stats out of it. https://github.com/axemclion/browser-perf looks like our best bet at this stage.

[MaciekBaron]

I was also very surprised that the article "introducing" this approach hasn't even mentioned performance.

The whole concept is based around using the least efficient CSS selectors possible. I think the article and this specification should at least mention this, because if you're an experienced front-end developer, this is the first question that would come to mind. This can not only slowdown the load of the page, but any interactions with it too due to invalidating the layout. Performance has improved, true, but we are still talking about big differences (benfrain's testing method is questionable, other tests show a ~20% 60% slowdown). From my experience, rewriting and improving selectors can bring a visible performance benefit to a website. I am intrigued to see results from actual pages using this approach.

[eltonmesquita]

@MaciekBaron I think the reason the performance wasn't mentioned was because it is not the focus of the method. The whole idea behind AM is to offer a sane way of writing CSS. It's up to the developer measure if it'll be a good fit for the project or not.

I'll not lie to you, my personal tests didn't have a favorable result for AM, with pages increasing its time to parse to close to 1s in the worst case scenario. But, it still needs much more testing. Besides the official tests, I'm creating my own testing page to emulate an edge case, a hard to parse page (lots of pseudo-elements, page paintings and so on) as we got to be sure of everything.

But let's say AM ends up almost unusable because of its performance (something absurd, actually), the solution is not just give up of it, but keep pushing it forwards so it can get usable one day. Browsers are evolving so fast these days that I think that it would be relatively easy to browsers match or get close of the class performance. Of course, they would change only if we keep pushing util it become a general problem and they have to make things work properly (as happened before with lots of stuff).

So, I think that the important now is to "finish" the specs and just test, so people who use it can be aware of the pros and cons...

[yuvii]

@eltonmesquita

of course that's not the focus. The focus is to create a hype around a needless idea that helps nothing (makes the code prettier? Come on, there are better ways to do this). You said it yourself - it effects the load time, but you're still eager to push it on, despite the fact that's it's clearly a bad design idea that produces even worse code that resembles old forgotten html4 attributes (remember size="" and font=""? Yeah, those are dead for a reason).

And why push it? because "maybe sometime in the future, browsers will fix our terrible code for us". I was skeptical from the start, but the discussion here is just proving more and more why this is a bad idea. I can't see why anyone will ever use this at all.

[eltonmesquita]

@yuvii It's your opinion, its not a fact as it's not a proven "bad design". It's your right to dislike it and even be against it, but it doesn't validate anything.

And why not push it? The benefits might be bigger than just doing nothing. If you don't like AM just ignore it. When you have facts proving it's a terrible idea worth killing, just show us! Don't just try to "steal" the buzz from it with a harsh attitude...

Peace man!

[geelen]

Well feel free to stop contributing to the discussion then @yuvii. There is virtually no similarity between size and font attributes and AM, beyond the most superficial aspects. If you'd like to argue for a 'better way to do this', I'd love to hear it! AM is still in its infancy and we need all the suggestions we can get, but please raise another issue.

I'm seeing similar results to @eltonmesquita - on highly complex pages, the values variant of the performance test is awful (1s penalty), but there seems to be a tipping point on the number of elements in the DOM for that to occur. The main problem right now is getting reliable, repeatable, statistically valid measurements for a variety of real-world use cases. http://www.webpagetest.org/ gives us some data but network performance variability is confusing things.

Once we have a reliable performance test we can get a feel for where the tradeoffs will be. My feeling right now is sites over 300-500kb of HTML + CSS combined (before gzip) see unexpectedly bad performance, but I need harder data before I can make that recommendation.

The reason performance wasn't considered in the first release is because the =~ matcher is _precisely_ the same operation as the class matcher. Both are matching space-separated separated tokens in an attribute value. So, while current implementations for AM markup might be slow, there's not actually anything harder about AM syntax than class syntax, it's just that browsers aren't optimised for it. But browsers are getting better all the time!

Just an aside, as I've looked in rework, it would be fairly trivial to convert AM HTML & CSS into class-based markup as a deploy step for performance reasons. It would allow you to experiment with AM markup on a conceptual level, without any performance degradation in the short term. If AM becomes popular and if browsers start to optimise the selectors more efficiently, then we can back out that process and serve the original markup (since it's still valid CSS). Small projects wouldn't need to bother, either. In that way it'd be like a performance polyfill for large sites. Does that make sense?

[MaciekBaron]

The reason performance wasn't considered in the first release is because the =~ matcher is precisely the same operation as the class matcher.

I'm not sure what you mean exactly by that but:

.myclass

Is not the same operation as

[class=~myclass]

Which is exactly the same as

*[class=~myclass]

.myclass translates into "find all elements with the myclass tag", while [class=~myclass] translates into "find all elements, then from all elements choose the ones that have the myclass class". This is not the same operation. By design, every selector using this method will first select all elements in the DOM and then narrow the search down, because every selector will be using a universal selector. And this has nothing to do with "browsers not being optimised for it", they are doing precisely what the selector is asking them to do.

[yuvii]

@eltonmesquita of course that's my opinion. When I first read about this I thought it was a bad idea, so I came here and joined the discussion, with the intent of listening to what you guys have to say, wanting to see if I'm judging this wrong. Maybe my knowledge of web development is antique. I dunno.

Instead, I saw explanations about how "browsers will change" and how "questions about performance are misunderstanding the point behind AM". I'm sorry, but those replies are avoiding the very real problem here.

It also seems to me like you guys are focusing on the wrong problem here. Who cares if the html isn't readable? What makes good development easy to maintain and readable is the behind-the-scenes tools you build it with. The prospect of actually writing HTML or CSS (instead of using one of the million tempting systems available and LESS\SCSS tools etc.) seems weird to me at this point of web development. I just don't see the reasoning - I can write readable variables in LESS that will output something less readable, but why does that matter at all? HTML5 allows custom tags. Why do we need custom attributes? And to top this all off, this "new system" entails a possible performance problem.

Anyway, I'm not convinced. But I'll keep checking up and see how this develops. Good luck you guys, hope you're not wasting your time.

[geelen]

@MaciekBaron Sorry, not the same operation in practice, the same operation in principal. As in, .class-name is defined as being equivalent to [class~="class-name"]. So clearly there's some optimisations taking place to make classes so fast (cause they are _fast_). And those operations could theoretically be applied to making the ~= selector fast too.

[jasonkarns]

I would imagine the classname performance optimization has little to do with the selector itself, and everything to do with classnames likely being indexed in the DOM. I'm only guessing here, but I wouldn't be surprised to see [class~=class-name] have the same performance as .class-name. (If the engine recognizes the attribute as class and makes use of the index.)

If the performance improvement is via a classname index, then browsers would have very little room to improve the performance of arbitrary attribute selectors without consuming gobs of memory. Assuming they do create an attribute index, it would be nearly as large as the DOM itself, thus removing any benefit to the index at all and simply serving to consume ever more bytes of RAM.

On Thu, Sep 11, 2014 at 10:44 AM, Glen Maddern notifications@github.com wrote:

@MaciekBaron https://github.com/MaciekBaron Sorry, not the same operation in practice, the same operation in principal. As in, .class-name is defined as being equivalent to [class~="class-name"]. So clearly there's some optimisations taking place to make classes so fast (cause they are fast). And those operations could theoretically be applied to making the ~= selector fast too.

— Reply to this email directly or view it on GitHub https://github.com/amcss/attribute-module-specification/issues/7#issuecomment-55274047 .

[MaciekBaron]

Sorry @geelen but it's like saying #mydiv and html body * div#mydiv are the same operation in principal only because in the end they select the same element. However, these are computationally completely different tasks. The same goes with comparing .class with *[class~="class"] – you might think that "they do the same thing", but computationally they are different, especially when you start using custom attributes. For this to work, browsers would have to start indexing all attributes. However if you can prove that performance is not an issue (and it seems to be, making this a huge obstacle), only then we can start discussing whether it actually improves code readability (which is something I personally disagree with, but that's just my opinion and a should be raised in a separate discussion).

[geelen]

Those two examples are really different. One has exactly the same amount of information, one has significantly more. But even though html body * div#mydiv contributes extra information, styles are interpreted right-to-left, so computationally that would be filtering a list of 1 after the first selection finds the #mydiv, so it wouldn't make much difference to performance. Point is, implementation and information are different, and AM is optimised for information.

As I've said many times, if you want to ask questions about readability/applicability/etc, please do so in another issue. I want to have these discussions, I just don't want to confuse the discussion.

[MaciekBaron]

But even though html body * div#mydiv contributes extra information, styles are interpreted right-to-left, so computationally that would be filtering a list of 1 after the first selection finds the #mydiv, so it wouldn't make much difference to performance.

I'm afraid this again is incorrect. Yes, styles are interpreted right to left, and this is precisely why it wouldn't be filtering a list of 1 – after finding #mydiv it will still have to check whether it is a descendent of any element (*) which in turn is a descendant of body which in turn is a descendant of html.

But I digress. Even if future browsers optimise attribute selectors for all attributes, which seems difficult, older browsers will still struggle. At the same time, methods like BEM promote code that is very efficient and that many people find readable (a matter of opinion).

But again, if it can be proven that there is no significant performance drop, people might start considering to use this method. Good luck.

[gloparco]

I was very much interested in this idea after reading the original well written article. I even added it to my JS magazine (http://flip.it/PB323) - [sorry, not a shameless plug; thought it may be a good resource for some reading this]

Anyway, after reading through this thread, I have to say, I agree with yuvii, MaciekBaron, and others. The maintenance and aesthetic benefits that AMCSS provides are very much overshadowed by the performance impact that it brings along with it. It may be difficult to hear, and perhaps yuvii could have been a bit more diplomatic in saying it, but there are existing best practices, both in structuring/namespacing your code, and in utilizing preprocessing libs, that give you improved maintenance and aesthetics without sacrificing anything by way of performance.

I would suggest that the authors take a step back and really think about whether it is worth adapting or advocating AMCSS knowing the performance problems associated with it, when there are alternate approaches and techniques that, while perhaps not as elegant, will be adequate for the vast majority of development teams.

[6twenty]

@geelen commented earlier that it wouldn't be hard to have AM converted to traditional classes as part of a build step. So, even if performance is a valid issue, the overall method is still relevant and worthwhile because it could ease development and maintenance. Similar to CSS pre-processors like SASS.

[geelen]

Yeah exactly, except more like a polyfill it's still valid CSS.

I'd still like to get real data on performance so we can better understand what's causing the slowdown on large DOMs, and know when the performance of browsers improve (which, after a few conversations with peeps on the browser team, sounds like is happening anyway)

On 12 September 2014 01:36, Mike Fulcher <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

@geelen https://github.com/geelen commented earlier https://github.com/amcss/attribute-module-specification/issues/7#issuecomment-55270292 that it wouldn't be hard to have AM converted to traditional classes as part of a build step. So, even if performance is a valid issue, the overall method is still relevant and worthwhile because it could ease development and maintenance. Similar to CSS pre-processors like SASS.

— Reply to this email directly or view it on GitHub https://github.com/amcss/attribute-module-specification/issues/7#issuecomment-55343926 .

[MaciekBaron]

I'd still like to get real data on performance so we can better understand what's causing the slowdown on large DOMs

@gellen, I believe it's very clear why there is a slowdown on very large DOMs and, like I've said before, optimising browsers to support relatively quick attribute selectors is nearly impossible because of the requirements imposed by such solution (i.e. indexing all element attributes, drastically increasing memory usage etc) as mentioned by @jasonkarns. Universal selectors with custom attribute selectors will always be slower than everything else, so all you can hope for is that CSS selectors will be so blazingly fast that even when using the least efficient selectors (like in this case) there is no impact on the site's performance.

But having said all that, please do not treat our comments as attacks. If you want this methodology to be treated seriously, it needs serious performance analysis and evaluation, and this is what we're trying to do. I think it's great that you guys are trying to come up with a more readable methodology.

[yuvii]

Like @MaciekBaron said - the problem is this entire system relies on bad selectors. Even if browsers get better somehow, you're still saying "well, we hope browsers will fix our bad code for us". I think that's a flawed approach to begin with.

On the other hand, @geelen and @6twenty you also suggested that AM might be compiled by a pre-processor. That's actually not a bad idea - there are a lot of templating languages for HTML, but most of them are terrible \ hard to maintain \ unreadable (Ahem). Making one that takes BEM as the basic inspiration, with an emphasis on readability and breaking things up to reusable components for easier design would be a good idea.

[geelen]

I was actually suggesting a post-processor, like autoprefixer does for CSS, but for both CSS & HTML. For small sites or for when faster browsers come along, we can simply drop the processor (in that way it acts like a polyfill)

Also, you seem to still be conflating unacceptable-performance-on-large-DOMs with "bad selectors"/"bad code". Again, I've not got hard data, but anecdotally, attribute selector performance doesn't noticeably affect rendering speed on DOMs of < 100-200KB of combined HTML & CSS. But YMMV, so (always, regardless of AM or not) test your own sites and make decisions accordingly.

On 12 September 2014 14:37, Yuval Bar-On notifications@github.com wrote:

Like @MaciekBaron https://github.com/MaciekBaron said - the problem is this entire system relies on bad selectors. Even if browsers get better somehow, you're still saying "well, we hope browsers will fix our bad code for us". I think that's a flawed approach to begin with.

On the other hand, @geelen https://github.com/geelen and @6twenty https://github.com/6twenty you also suggested that AM might be compiled by a pre-processor. That's actually not a bad idea - there are a lot of templating languages for HTML, but most of them are terrible \ hard to maintain \ unreadable (Ahem http://jade-lang.com/). Making one that takes BEM as the basic inspiration, with an emphasis on readability and breaking things up to reusable components for easier design would be a good idea.

— Reply to this email directly or view it on GitHub https://github.com/amcss/attribute-module-specification/issues/7#issuecomment-55396658 .

[gloparco]

@geelen you may be correct, but the larger point is that if you deem the performance acceptable for your current state 100-200kb project, there exists the possibility (probability?) that your project will grow over time, and that performance will at some point become an issue. It is inherent in this solution. In that sense, I agree with @yuvii that it's a bad idea to use a solution known to have potential performance issues, just because it seems to not affect you for the time being. What is more important - slightly more readable code, or the performance of your web site/app?

[yuvii]

There's a difference between using attribute selectors when you need them to using them as the basis for your entire design. The first makes sense to me, the latter... Less so.

But go ahead, prove me wrong. I might not be a good diplomat when it comes to phrasing myself, but I'm open to hearing new ideas. I'm currently unconvinced, but who knows.

[geelen]

I'm suggesting performance of AM is fine un-post-processed up to that point, at which point your site is complex enough to use a post-processor for performance. Pretty much the same way you can roll with unminified JS for a while.

I guess my frustration comes from the idea that AM is somehow a fixed, finished, polished thing. We've been kicking this idea around for only a few months, and I believe it's more useful to take a 'what-if' position when it comes to designing an API, then follow it closely and see where it leads, and how it feels. That's where the project is at at the moment, and so criticisms like "it's not worth pursuing" are kinda missing the point.

But yeah, if this thread proves anything, it's that hard data (more so a real methodology for collecting it) is sorely needed! And developing a post-processor might mitigate performance troubles and let us all experiment with AM on sites of varying sizes as a conceptual exercise, and figure out where to go from there :)

On 12 September 2014 15:13, Yuval Bar-On notifications@github.com wrote:

There's a difference between using attribute selectors when you need them to using them as the basis for your entire design. The first makes sense to me, the latter... Less so.

But go ahead, prove me wrong. I might not be a good diplomat when it comes to phrasing myself, but I'm open to hearing new ideas. I'm currently unconvinced, but who knows.

— Reply to this email directly or view it on GitHub https://github.com/amcss/attribute-module-specification/issues/7#issuecomment-55401004 .

[gandhiShepard]

Can't Paul Irish settle this for us? As he says, "If you aren’t getting 90+ Page Speed scores, it’s way too early to be thinking about selector optimization."

Let's not forget that his article, "* { Box-sizing: Border-box } FTW" suggests a fix for the box-model that IS in fact slightly slower! But it resolves box-model madness.

He used Speed Tracker to check the performance https://developers.google.com/web-toolkit/speedtracer/.

I care about the performance issue, and I also love the cleverness of this approach to move the discussion of CSS best practices forward.

[MaciekBaron]

@geelen How thoroughly have you tested the 100-200KB CSS website? Have you tested how it affects CSS reflow? Because the main problem with universal selectors (with attribute selectors) is that they will be considered for every reflow, which means that whenever a reflow is triggered, every single css selector would be considered for the reflow.

[jasonkarns]

People are missing the fact that performance is not limited to CSS selectors, paints, reflows. If one takes the AM approach, then all (most) DOM querying would be done using attribute selectors as well. This is a huge consideration for fat client apps.

On Fri, Sep 12, 2014 at 10:07 AM, Maciek Baron notifications@github.com wrote:

@geelen https://github.com/geelen How thoroughly have you tested the 100-200KB CSS website? Have you tested how it affects CSS reflow? Because the main problem with universal selectors is that they will be considered for every reflow, which means that whenever a reflow is triggered, every single css selector would be considered for the reflow.

— Reply to this email directly or view it on GitHub https://github.com/amcss/attribute-module-specification/issues/7#issuecomment-55407966 .

[MaciekBaron]

That is true @jasonkarns, a quick test shows that using document.querySelector() with attribute selectors is nearly 4 times slower than using classes.

[eltonmesquita]

@MaciekBaron, I'ver run the test in a few more browsers other than chrome and there's a lot of fluctuation... See Firefox? And Safari?

I think we need more data before anything...

[MaciekBaron]

@eltonmesquita All tests but Firefox show at least 2 times slower results (Firefox just seems slow in terms of the class selector). I agree this varies between browsers.

[eltonmesquita]

And the more we test less conclusions can be taken... But, it's clear to me that browsers can get better at selecting atributes. Webkit and Gecko are showing that it's possible.

BTW Safari 6 is kinda crazy, right?

[jcracknell]

Everything I am seeing suggests that in the worst case, the performance of attribute module style selectors is at worst four times slower than the equivalent class selectors. This relationship seems to hold regardless of the number of nodes in the document, so if we frame our conclusion in terms of runtime analysis there is no appreciable difference, as O(n) == O(4n).

Basically I think that unless selector performance is already an issue for you, it is unlikely you will notice the difference (although I would be interested to see results for Internet Explorer).

I had wanted to make multiple clones of this at varying document sizes, however I cannot get JSPerf to stop flagging it as spam:

• 100 copies: http://jsperf.com/attribute-module-selector-performance-100
• 10000 copies: http://jsperf.com/attribute-module-selector-performance-100/2

[MaciekBaron]

@jcracknell, sorry, but you're confusing problem complexity with performance.

Indeed when describing the problem's complexity using Big O notation, if the number of nodes doesn't matter then yes, the complexity of both problems is the same since O(n) == O(4n) and n → ∞. But concluding that because of this we have no appreciable difference in performance is a major misunderstanding of what you are talking about.

If solution B was 1000 times slower than A, you cannot say that because of O(n) == O(1000n) there is no appreciable difference. The complexity is the same, but performance will be different.

So, Big O notation has nothing to do with what we are discussing here, because we are not discussing the problem's complexity but the performance of this "solution".

This test has only checked "query selections", we also need to check how it affects document reflow (now that all selectors are considered for the reflow), document load time and so forth. All I keep saying is that even if the performance impact is relatively small, this should be mentioned in the specification.

[callistino]

Very inefficient and unscientific test of AM-CSS with bootstrap components page. I only updated the css/html still missing the js so there may be some perf hit with all that js not finding the classes to work on. http://getbootstrap.com/components/ http://callistino.github.io/bootstrap/components/ Open the dev tools -> network tab and see how long it takes to complete rendering

[MaciekBaron]

Wow, that's even slower than I've expected. Reflowing and redrawing is so much slower compared to the standard approach.

[Jayphen]

It's been quiet here for a while — what is the latest thinking on this? Has this project been abandoned?

[geelen]

Not at all, just got back from Berlin and had heaps of work to do. I'm using AM in a big way on this job and have a bunch more things to add on both design and performance. But no time to write anything down!

On Wednesday, October 29, 2014, Jayphen notifications@github.com wrote:

It's been quiet here for a while — what is the latest thinking on this? Has this project been abandoned?

— Reply to this email directly or view it on GitHub https://github.com/amcss/attribute-module-specification/issues/7#issuecomment-60870956 .