Suspicious Dish posted:

I'm not joking when I say that in several of my projects, I replaced for(let foo of bar) with for(let i = 0; i < bar.length; i++) let foo = bar[i]; to a significant performance boost. This was after I profiled and saw it was an issue, and then fixed it.

This stuff matters, it really does. The compiler can often do a really crap job with some of this stuff.

Chas McGill posted:

Hmm I think I need a new host. Cheers for the advice.

Joda posted:

Wait, really? You'd think the array iterable if anything would be optimised in the engine

Nolgthorn posted:

Met somebody once, I was conducting their interview, and they wrote all of their loops in reverse.

code:

for (let i = 10; i >= 0; i--)

So I asked him why he was doing that, he said it was more performant.

Nolgthorn posted:

Even faster calculate the length ahead of time

code:

const j = bar.length;
for(let i = 0; i < j; i++) {
    const foo = bar[i];
}

But true, for..of is notoriously slow. I cannot get enough of it.

smackfu posted:

(Unless length is actually calculated on demand, doubtful this is an improvement at all.)

necrotic posted:

Is length not a stored value that only changes when you use array mutation methods? Why would it have to do anything except read a value?

necrotic posted:

No, I mean literally the value at array.length. Not some code analysis.

roomforthetuna posted:

I think the point being made is it probably *is* a very small speed improvement, because putting the length in a local variable is one lookup per iteration, whereas getting it out of array.length is two (one for the location of the array and another for the location of the array's length property). Perhaps even worse if array.length goes through a getter function. Sure, using array.length each iteration isn't making the loop O(n^2) or anything, but in a non-compiled language using a plain variable is almost certainly [very slightly] faster than using a member property.

necrotic posted:

I was responding to Joda, who implied the length is computed every time you call array.length.

Joda posted:

Yes, but how will you make absolutely sure that the array is never mutated? At what point do you stop resolving code paths and how do you know that someone isn't doing some crazy reflection poo poo somewhere or something. What if we get proprer threading. There's simply no reliable way to implement this other than taking the programmer intent at face value, and getting length each iteration.

Dumb Lowtax posted:

If you assign it to a local, would that most likely get compiled to some CPU register value that the next lines can access? If you just let it do "array.length", that would probably compile to a single address rather than an indirection, right? I assume that address would go to somewhere cached nicely and maybe even directly get to stay a register throughout the loop too

Joda posted:

That all depends on whether or not something aliases with it.

Dumb Lowtax posted:

What's an example of this?

Osmosisch posted:

Anyone who claims to care about performance that much and then uses postfix in/decrement is just weird to me.

The widespread use of postfix operators where the cached value is irrelevant is just so irritating to me (and yeah I know it will usually get compiled into prefix but ugh. Write what you mean).

Doom Mathematic posted:

Are you saying prefix increment/decrement is faster than postfix increment/decrement in that context?

Osmosisch posted:

Probably not in that context, as I tried to explain with the bit about the compiler. It's just that I'd expect someone who is being anal about performance to not risk it.

Doom Mathematic posted:

Is there any context where there's a difference in performance, though?

Munkeymon posted:

After doing i++ for years just because that's how all the examples I learned from do it, I thought about it for a minute and realized that ++i is the operation I actually wanted/needed, so started doing it that way instead. Like if you have two equivalent functions that mutate a thing but one returns a value that you just don't use, I stop and wonder why.

huhu posted:

I'm confused, do you not have access to a backend? How are you serving your code? Do you have a DB?

roomforthetuna posted:

I assume the prevalence of i++ is because ++i doesn't follow the pattern of almost every other mutation operation, leading with the thing that is to be mutated.

AFashionableHat posted:

Suspicious Dish posted:

I don't understand why anybody would willingly use Babel, for instance.

AFashionableHat posted:

Folks who write JavaScript rather than TypeScript (Flow, Elm, ReasonML people--you're excused)...why? Inertia/legacy? Employer won't do it? A dislike of it? To me it feels like moving backwards, but it's shaping up as though I'm going to have to end up somewhere where that's the norm again and I'd really like to understand the mindset involved.

Lumpy posted:

"I have 3 days to write this, and I don't think learning typescript and getting the tooling all set up will fit in that."

Suspicious Dish posted:

I write TypeScript because I find it worth the hassle, but 99% of these stupid bundler or compiler things are the most fragile pieces of software I've ever used, and manage not only to screw over your computer, but often browser devtools as well.

I'm currently using Parcel. It's the least bad of these stupid bundler things that I've used and it's still basically 100% busted.

I don't understand why anybody would willingly use Babel, for instance.

roomforthetuna posted:

This is good estimating.