Not really. Sure it adds some overhead but it's well optimized and not overly significant, especially for incremental collections. It can even pay for itself by defragging your memory, making subsequent allocations cheaper. The big problem with GC is the pauses it causes when doing full "stop the world" collections, which can be noticeable in animations, or even on server-side in high-volume latency-sensitive services. But there are strategies you can use to reduce or eliminate the need for those if you're willing to put in the effort (beyond the scope of this comment).

Note that pauses _can_ happen in non-GC languages too, if you have to delete something that references a bunch of other stuff that you have to recursively delete as well, though in the real world this is not very common.

GC changes the performance profile of allocations, specifically. If your code is written to use static memory you won't experience GC pauses, but languages like JS that employ GC intentionally steer you towards allocating to do, e.g. string processing, so you have to go out of your way to make JS fast in this way.

WASM now has GC, since a goal is to support alternative scripting environments and e.g. run a mixture of Rust and Python code in the browser.

WASM now has GC support as well, https://developer.chrome.com/blog/wasmgc