|
|
Lately I write very long comments on things I find around the internet and then for some reason don't have the kidneys to post them. I don't want them to go completely to waste, so here's one regarding http://24ways.org/2011/your-jquery-now-with-less-suck Is the ops/sec the number of times it can find an element of the type in question? Or is it somehow the number of elements it hits while searching? My guess would be the first, because measuring the second would be hard (or impossible?) and less relevant. The reason I ask is that the test just gave me 569 ops/sec for the worst element, the :hidden pseudo class. I know, I know, it is possible for people to write a page so hairy that it actually selects hundreds of :hidden elements, but how common is this? The attribute selector reads at 15,000 ops/sec. I can see that some of the browsers gave something like 4,000 for that. Still, if hundreds of :hidden selectors is a lot per page, then hundreds more attribute selectors is really a lot. I can think of a page -- made by one of about a thousand users using a tool that is under my care -- that has hundreds of entries in their blog-like list. We ran into problems with this because it was draggable, but the largest part of the solution was to switch to using jQuery from prototype. Some more responsiveness came from using selectors differently, as you say. That said, it is easy to spend a lot of time programming and debugging just because you're afraid something is going to be slow. I picked up something from a company called Art & Logic (artlogic.com) a while back about best practices, and I have been convinced since then that it is smart thinking; you should (paraphrasing from them) maintain good practices, but don't prematurely optimize. Prematurely optimizing can lead to confusing code, lost time, duller features, and -- yes -- *slower* code. You shouldn't very often side with optimizing when there are benefits to not optimizing -- until you find your code running too slow. In the real world there are definitely trade-offs. If you just think about the difference between quicker sorting algorithms and slower sorting algorithms, you'll see a lot of these. Luckily, you don't have to rewrite sorting algorithms, which removes some of the tradeoffs. It is quite useful to know which selectors are faster, especially if you're already in a situation where you need to optimize. But what I can't answer is this: Are we benefiting from the very many articles about optimization more than we would if they were prefaced by saying that optimization can often do more harm than good? A lot of examples of optimizing javascript could lead to reduced optimization of server-side scripting (eg trying to make elements easier to select), can lead to more convoluted code on both sides of the client-server relationship, can discourage or slow down people who are just learning, discourage the implementation of new kinds of interface interaction, increase time to implement and correspondingly reduce features/functionality, and can generally just lead to more stress than is absolutely necessary. And yes, it can lead to less-optimized code, especially if someone tries to learn several ways to optimize and try to flawlessly apply them from that point on. This might not be the intention, but it might be a good idea to point that out. |
|
|
Bipolar II Disorder
|
|
|
Dear developers, "chocolate == tasty" should not be the same as saying "chocolate is tasty". When a program says "a == b" it would be backwards to suppose that the expression was true and then leap to the conclusion that "a" really was quite "b". It would be closer to say "a = b", because then we would all be able to look at "a" and see that it did indeed contain "b". In this case you would say "chocolate = tasty", which sounds funny because it sounds like you're forcing chocolate to be tasty. Unfortunately, (or fortunately) programs do not have an effect on reality, so don't be afraid to assign "tasty" (which I assume is some kind of taste literal) to "chocolate". It won't force chocolate to taste good or force anyone to believe that it does. If you want to be really picky about it you could come up with something more awkward, like know_that(chocolate, tasty) Or here's an object oriented approach you.communicate_description(chocolate, tasty) Or how about command-line? echo "tasty" > chocolate But that would be crazy. Sincerely,
|
|
|
I left you a facebook comment,
or was it a videomail?
what was I talking about? |