search

tc39 / proposal-iterator.range

A proposal for ECMAScript to add a built-in Iterator.range()
https://tc39.es/proposal-iterator.range/
MIT License
487 stars 13 forks source link

Performance problem #70

Closed aquapi closed 5 months ago

aquapi commented 5 months ago 
          > So you are saying that you will waste some memory for developer experience?

That is what I am saying, yes. All languages do this. Like I said, performance is one important aspect to consider for new features, not the only one.

Explain to me why this feature should exist.

No, I won't.

Originally posted by @tabatkins in https://github.com/tc39/proposal-iterator.range/issues/69#issuecomment-2073650812

I already stated above that other languages do that for performance reasons. You don't seem to understand my point. Also why are you closing the second issue I'm not violating anything there.

In low-level languages functions like range() can be optimized to the same exact machine code as the normal for loop one, but it is not the case in JavaScript.

Jack-Works commented 5 months ago

The locking issue is not so friendly I agree :)

But I also agree with what Tabkins said, performance is one important aspect to consider for new features, not the only one. I don't recall a concern about performance from other TC39 members (including JS engine developers who are very sensitive about performance) so I think this is OK.

aquapi commented 5 months ago

@Jack-Works But does it do anything else other than just there for convenience?

aquapi commented 5 months ago

Remember that for of has been there since 2015 and after all of that time it is still slower than a c-style for loop :).

And as I already stated above, that convienient feature in other languages don't have an effect on performance at all, and it can sometimes improve performance, but I don't see the similar thing for JavaScript

Jack-Works commented 5 months ago

Remember that for of has been there since 2015 and after all of that time it is still slower than a c-style for loop :).

Yes, we know it. We're balancing between all those concerns and we agree it's better in the language than not.

aquapi commented 5 months ago

I see this feature can be a bit useful for string iterations though, not numbers.

And there will be more people complaining about performance and its improvement to the language other than just being convenient if this reaches stage 3, not just me :).

Right now a lot of people that I asked seems to dislike this feature as of it being useless :/ @Jack-Works

aquapi commented 5 months ago

image For a lot of people including me this doesn't seems to be a good reason to add a feature in. Also this feature doesn't improve performance at all. When you take an example of another language that has range() built in you need to understand why they have it. In the specific case of Python it is there for both convenience and performance

ljharb commented 5 months ago

It’s a good reason for a great many of us - and it doesn’t hurt to have it added if you’re not using it.

Jack-Works commented 5 months ago

I see this feature can be a bit useful for string iterations though, not numbers.

I leave the possibility to add it in the future. The API throws for strings, not coercing them, so we can add Unicode range in the future (if we think it's useful).

Also this feature doesn't improve performance at all.

It's not for "improving performance".