On 12/23/2014 08:28 PM, Dave Tian wrote:
Hi,
Hi, please do some things when you post new questions:
1) identify your Python version. In this case it makes a big
difference, as in Python 2.x, the range function is the only thing that
takes any noticeable time in this code.
2) when posting code, use cut 'n paste. You retyped the code, which
could have caused typos, and in fact did, since your email editor (or
newsgroup editor, or whatever) decided to use 'smart quotes' instead of
single quotes. The Unicode characters shown in "Testing code" below
include
LEFT SINGLE QUOTATION MARK
and
RIGHT SINGLE QUOTATION MARK
which are not valid Python syntax.
There are 2 statements:
A: a = ‘h’
B: b = ‘hh’
According to me understanding, A should be faster as characters would shortcut
this 1-byte string ‘h’ without malloc;
Nope, there's no such promise in Python. If there were such an
optimization, it might vary between one implementation of Python and
another, and between one version and the next.
But it'd be very hard to implement such an optimization, since the C
interface would then see it, and third party native libraries would have
to have special coding for this one kind of object.
You're probably thinking of Java and C#, which have native data and
boxed data (I don't recall just what each one calls it). Python, at
least for the last 15 years or so, makes everything an object, which
means there are no special cases for us to deal with.
B should be slower than A as characters does not work for 2-byte string
‘hh’, which triggers the malloc. However, when I put A/B into a big loop
and try to measure the performance using cProfile, B seems always faster
than A.
Testing code:
for i in range(0, 100000000):
a = ‘h’ #or b = ‘hh’
Testing cmd: python -m cProfile test.py
So what is wrong here? B has one more malloc than A but is faster than B?
In my testing, sometimes A is quicker, and sometimes B is quicker. But
of course there are many ways of testing it, and many versions to test
it on. I put those statements (after fixing the quotes) into two
functions, and called the two functions, letting profile tell me which
was faster.
Incidentally, just putting them in functions cut the time by
approximately 50%, probably because local variable lookup in a function
in much faster in CPython than access to variables in globals().
There are other things going on, In any recent CPython implementation,
certain strings will be interned, which can both save memory and avoid
the constant thrashing of malloc and free. So we might get different
results by choosing a string which won't happen to get interned.
It's hard to get excited over any of these differences, but it is fun to
think about it.
--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list
