[noelwelsh]

It's not a given that GC is slower than manual memory management. See, for example, this work:

http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf

In a copy collector the GC time is proportional to the amount of live memory -- garbage is free. In FP-style programs (lots of short-lived allocations) GC can be essentially free.

The other main source of slowdown is to do with boxing and type checks. Accessing all data in a naive implementation of a dynamically typed language involves at least one type check and typically one pointer indirection to unbox the data. This can kill performance relative to the unboxed and unchecked equivalent. Consider, e.g., floating point operations -- they run in 1 cycle. If you add type check (2-3 cycles perhaps) and pointer indirection (10 cycles if it's in the cache) you can see how massive slowdowns easily arise.

Modern JS VMs will remove most of this cost. I doubt Python and Ruby do.

Basically, I would say it really depends on the interactions between the program and the language implementation.

[algorias]

> Modern JS VMs will remove most of this cost. I doubt Python and Ruby do.

In the python case, pypy removes this cost whenever it can. The less you use dynamic features like duck typing, the faster your code gets.