I wonder if bytearray([97,98,99]).decode('latin-1') is faster still. Edit: Yup, it is. 3x faster. https://gist.github.com/anonymous/18e372e8d0173e77b5c405920d...
Even shorter: bytes([97,89,99]).decode()
Fast Python loops
21–30 of 54 posts
Re: Fast Python loops
#22I wonder if bytearray([97,98,99]).decode('latin-1') is faster still. Edit: Yup, it is. 3x faster. https://gist.github.com/anonymous/18e372e8d0173e77b5c405920d...
It's arguably marginally more readable as well.
Re: Fast Python loops
#23Earlier quoted context omitted.
Was thinking exactly the same. Plus you save an import. And no need to wrap it in a function since it's a short method call on a built-in. Would bytearray([97,98,99]).decode('ascii') be even faster ?
It would fail when you pass it 128. He's passing in values from 0-255. "Ascii" is sort of a misnomer in his post.
It's better to fail than to convert something that probably isn't latin1!
Re: Fast Python loops
#24A big problem here, though, is that > array.array('B', list).tostring() is not terribly readable or beautiful. In fact, I think I'd need a comment to explain that it's typecasting elements of a list strings to ints. Optimizations like this are an identity crisis for Python (and have been for a long time, as evinced by the age of this essay): Is it focused on being human-readable and otherwise compliant with the Zen o…
The people complaining about performance are always going to be louder.
Re: Fast Python loops
#25A big problem here, though, is that > array.array('B', list).tostring() is not terribly readable or beautiful. In fact, I think I'd need a comment to explain that it's typecasting elements of a list strings to ints. Optimizations like this are an identity crisis for Python (and have been for a long time, as evinced by the age of this essay): Is it focused on being human-readable and otherwise compliant with the Zen o…
The people complaining about performance are always going to be louder.
Sure, but what I'm saying is that, if the underlying philosophy of Python holds water, then we need to find ways of to overcome this tug-of-war and ensure that the most beautiful ways are also the most (or among the most) performant.
Re: Fast Python loops
#26Or you could just use PyPy and see these numbers:
('f1',)
0.328
('f2',)
0.525
('f3',)
0.269
('f4',)
0.297
('f5',)
0.041
('f6',)
0.188
('f7',)
0.103
('f1',)
0.06
('f2',)
0.08
('f3',)
0.115
('f4',)
0.063
('f5',)
0.027
('f6',)
0.065
('f7',)
0.024Re: Fast Python loops
#27Earlier quoted context omitted.
The python timings are for 1000 iterations. You are currently comparing apple to 1000 apples :)
You mean 100 iterations instead of 1000? I have noted "took 0.000183 (For one iteration)" :)
No, it's 1000. Specifically, 100 iterations of 10 calls. Why he did it that way, I don't know.
Re: Fast Python loops
#28> if you're considering different versions of an algorithm, test it in a tight loop using the time.clock() function.
...but if you are anyway experimenting with your code in a Jupyter notebook, then you could just use %timeit [1] or %time [2] magics to measure execution times and benchmarks without writing any additional code.
[1] https://ipython.org/ipython-doc/3/interactive/magics.html#ma...
[2] https://ipython.org/ipython-doc/3/interactive/magics.html#ma...
Re: Fast Python loops
#29Earlier quoted context omitted.
It would fail when you pass it 128. He's passing in values from 0-255. "Ascii" is sort of a misnomer in his post.
It's better to fail than to convert something that probably isn't latin1!
Well, it's not clear what behavior he was looking for. And not possible to compare speed without an encoding that works for 0-255.