News for hackers. Stuff that matters.
Re:A 10x Faster TypeScript by do_not_redeem on Tuesday March 11, 2025 @11:16AM (#43333317)
Well-optimized JavaScript can, if you jump through hoops like avoiding object creation and storing your data in `Uint8Array`s. But idiomatic, maintainable JS simply can't (except in microbenchmarks where allocations and memory layout aren't yet concerns).

In a game engine, you probably aren't recreating every game object from frame to frame. But in a compiler, you're creating new objects for every file you parse. That's a huge amount of work for the GC.

Re:A 10x Faster TypeScript by AshleysBrain on Tuesday March 11, 2025 @12:35PM (#43334220)
I'd say that our JS game engine codebase is generally idiomatic, maintainable JS. We don't really do anything too esoteric to get maximum performance - modern JS engines are phenomenal at optimizing idiomatic code. The best JS performance advice is to basically treat it like a statically typed language (no dynamically-shaped objects etc) - and TS takes care of that for you. I suppose a compiler is a very different use case and may do things like lean on the GC more, but modern JS GCs are also amazing.

Basically I'd be interested to know what the bottlenecks in tsc are, whether there's much low-hanging fruit, and if not why not.

Re:A 10x Faster TypeScript by Yoric on Tuesday March 11, 2025 @12:52PM (#43334469)
Note that games are based on main loops + events, for which JITs are optimized, while compilers are typically single run-to-completion, for which JITs aren't.

So this might be a very different performance profile.

*edit* I had initially written "single-pass", but in the context of a compiler, that's ambiguous.

Re:A 10x Faster TypeScript by immibis on Tuesday March 11, 2025 @12:59PM (#43334563)
In other words you write asm.js, which is a textual form of WebAssembly that is also valid Javascript, and if your browser has an asm.js JIT compiler - which it doesn't because it was replaced by WebAssembly.