Encouraging slow iteration

[toastyghost]

page/performance/append-outside-loop.md:

Using $.each to traverse a normal JS array in an unrelated article seems like setting a bad example when native loop structures are literally 53 times as fast. (It's the performance section, after all.)

[scottgonzalez]

Looping is not your bottleneck, for sure.

[toastyghost]

So the difference between the first two numbers here is significant enough to warrant a separate article in the same section, but the difference between them and the third isn't worth mentioning?

[scottgonzalez]

Well, those don't look like legitimate comparisons to me. The for loop is likely being compiled away to nothing.

[toastyghost]

Fair point, but I got the same order of magnitude when rerunning the test with some work inside the loops:

And what testing did you do to arrive at the opinion that mine wasn't legitimate? Because if the answer is "none", that's more indicative of an entrenchment bias than anything about the numbers.

[scottgonzalez]

The answer is "none" because most microbenchmarks like this are meaningless, and many are incorrect. You still haven't shown a meaningful comparison because you're not doing any work that's even close to the work being done in the article. If your intent is to iterate over 100,000 items and generate DOM elements for all of them, you've probably git much bigger problems to deal with.

[toastyghost]

Then suggest a piece of work to put inside the loop that you consider substantial enough to make the test meaningful.

[scottgonzalez]

Why don't you take an actual example that you think should be updated on the site?

[toastyghost]

Because I'm not the one shooting down suggestions without providing my standard for judging so they can be improved upon.

Anyway, I already used an example from the site. It was the comment "do stuff", which you have here.

I'm not going to keep taking blind stabs at this without getting any constructive feedback. That's just not a good use of time. Please give me a ballpark of what you would consider to be significant amount of work to confirm or deny my assertion about $.each being slow, and I will modify the benchmark to meet this standard.

[agcolom]

@toastyghost Thanks for your message. I agree that the learn site should encourage and promote best practice, and I am interested in hearing from you on this topic and what the example here should be.

[arthurvr]

Please give me a ballpark of what you would consider to be significant amount of work to confirm or deny my assertion about $.each being slow, and I will modify the benchmark to meet this standard.

@scottgonzalez Any further thoughts?

[scottgonzalez]

I have no further thoughts. Premature optimization is terrible. Nobody has shown an actual performance problem here, so I stand by my statement that there is nothing to change.

[scottgonzalez]

Perhaps this will clarify my stance: We absolutely should promote developer ergonomics over unnecessary performance optimizations. When talking about performance, we should talk about how to identify actual problems and bottlenecks and document how to deal with the common problems. But we should never stray from common practices, obvious implementations, or "nicer" code just because there is a more performant implementation. There must be an actual driving force to change to performance-based coding.

[agcolom]

I think we can close.

[toastyghost]

"I have no further thoughts" Proceeds to write novel Still won't answer my question 3.5 months later Performance section of website still has shitty performance practices in examples

Yeah go ahead and close, nothing's going to get done here.

[arthurvr]

Actually, I do think this section has some serious troubles, but micro-improvements based on incomplete, premature benchmarks aren't a good idea. Instead I think the section should cover more of the tooling to measure things that actually matter. For example, browser devtools, or how to make reliable benchmarks.

[agcolom]

@toastyghost I'm sorry that you are taking my note this way. You didn't answer my message. Just to remind you that we are ALL volunteers. I was interested in hearing from you what your thoughts were and how this section should be changed. You chose not to answer. We are discussing at the team level how we can improve the section.

[toastyghost]

@agcolom Believe me, that wasn't directed at anything you said. And I must have missed the notification from your response in June, sorry about that.

The only suggestion I've made was shot down without any real feedback, and I'm sure as a volunteer you understand why I don't want to spend any more time on a trial-and-error approach like that.

@arthurvr I totally agree, and my original suggestion wasn't intended to be the basis for a comprehensive overhaul. It was intended to be the basis for a quick edit, removing a slow method from a page about performance. My quick bench to demonstrate this keeps drawing criticism, but without any challenge to the truth of my assertion or suggestions of alternatives.

[dmethvin]

I spend a lot of time optimizing web sites and I've never seen a case where $.each() turned out to be a bottleneck. That's why it's important to run real code in situ and not use microbenchmarks. Here is a V8 implementer dissecting your benchmark.. Note that V8 is even smarter today.

At this point in JavaScript evolution inside a browser, it's much more likely that you are going to have performance issues from forced layouts or synchronous events than from minor choices in coding procedures. JavaScript has just gotten that fast. A tutorial on how to use browser dev tools such as the waterfall diagram and profiler are out of the scope of this site IMO, but it wouldn't hurt to mention that as the way to find performance issues.

[toastyghost]

So interpreted is faster than native. Got it.

[agcolom]

@toastyghost Thanks for getting back to me :-) and thanks @dmethvin for a very detailed response.

[toastyghost]

@dmethvin That video was really interesting. Thanks for the link.