Hacker News Reader

Comment by hajile | Hacker News Reader

Making fast JS isn't some super-secret thing. Sure, there are weird cases like `x = y > z ? y : z` being 100x faster than `x = Math.max(y, z)`, but most performance improvements come from three simple rules:

1. Create an object with a fixed number of keys and NEVER add keys, remove keys, or change the data type of a key's value.

2. Make arrays of a set length and only put ONE type data type inside. If that data type is an object or array, all the objects/arrays must have the same type

3. Functions must be monomorphic (always called with the same parameters in the same order of the same type)

Do this and your code will be very fast. Do something else and it will get progressively slower.

Running the profiler in Chrome or Firefox is very easy and it will show you which functions are using up most of your processing time. Focusing on applying these rules to just those functions will usually get you most of the way there.

View on HN

... Until it's not. If your code needs to be predictably fast, it can't be fast the majority of the time, it needs to be fast all the time. It's not about painting your updates in a tenth of a second, it's about painting your video game scene in under 16ms, every time.

There's nothing you can do to guarantee your JS isn't passed inputs that trigger pathological cases. There's no linter that can guarantee that you're writing code in a way that is the fastest it can be (even with type checking!). Asking developers to be a human linter for the sake of consistent performance is a bad developer experience no matter your skill level.

WASM simply doesn't have this problem.

> There's nothing you can do to guarantee your JS isn't passed inputs that trigger pathological cases. ... WASM simply doesn't have this problem.

why doesn't this problem also apply to WASM?

How did you find out? Just by profiling or did you read some book/article about that topic?

i.e. basically use JavaScript as if it were a statically typed language.

Kinda. As long as you guard the boundaries of the parts that need performance, you can be a lot more flexible everywhere else. You see this in libraries like React where the external API is polymorphic, but they tend to pass through to calls that are monomorphic internally so performance is better.

I wish TypeScript helped more here. I'd prefer if it had a performance option that disallowed or at least warned about these kinds of things.

I wish we just ditched the JS legacy and had a properly statically typed language, with dynamism as a layer on top (like e.g. "dynamic" in C#), rather than underpinning anything.

Which is what wasm will, hopefully, give us in the long run. And ensure that said PL will have to remain competitive against the new contenders, since they can always replace it.

I think the reverse option is better. Add a `use types` directive to functions or modules. Inside those modules, use a very strict, structurally-typed ML-style type system that ensures good performance. If an untyped piece of code calls a typed one, coerce primitives and throw on objects that aren't a structural match.

Reply on news.ycombinator.com