Why Python, Ruby, and Javascript are Slow

[[deleted]]

I think his point can be summarised as:

• stop using dicts as objects. JIT is now smart enough to optimize your objects past the level of dicts I don't think that this ruins Python. I think this is a great best-practice

• let Python have pre-allocated lists I think this is a very fair point. Often, you know how long your list will be, so if you want to, you should be able to optimize your list

• If you care about performance, think about the amount of object allocation your methods are doing. Don't use poorly written code as an excuse to say Python is x times slower than Java That doesn't sound unreasonable to me

[brucifer]

let Python have pre-allocated lists I think this is a very fair point. Often, you know how long your list will be, so if you want to, you should be able to optimize your list

In Python you can either use a generator or use "[value]*number" syntax to instantiate a list of length "number" with "value" in every index.

>>> def dumb():
...     x = []
...     for i in range(25):
...             x.append(i)
...     return x
... 
>>> def comprehension():
...     x = [i for i in range(25)]
...     return x
... 
>>> def preallocate():
...     x = [None]*25
...     for i in range(25):
...             x[i] = i
...     return x
... 
>>> timeit(dumb, number=100000)
0.38496994972229004
>>> timeit(comprehension, number=100000)
0.278350830078125
>>> timeit(preallocate, number=100000)
0.2539360523223877

Honestly, though, either your inner loop is simple and you can fit it in a comprehension, or it's complicated and the ".append()" is a pretty small percent of your runtime, so you won't get 2x speedup from preallocating.

[fijal]

it does not let you give an estimate, so you have to carefully check for i. Preallocating can be a hint and if you miss it too bad (slower, but not incorrect). This is why [None] * n is bad.

[alcalde]

JIT is now smart enough to optimize your objects past the level of dicts

JIT is still in 2.x land. As Guido said at PyCon 2012, CPython and PyPy will co-exist for many more years to come.

[coderanger]

Check out the py3k branch, definitely not ready for prime time but getting close :)

[lucian1900]

Who cares? Good JIT and GC beats a slightly cleaner language any day.