>> Based on some ideas from Skip, I had tried transforming the likes of
>> "x in (1,2,3)" into "x in frozenset([1,2,3])"....
Fredrik> savings in what? time or bytecode size? constructed
Fredrik> micro-benchmarks, or examples from real-life code?
Fredrik> do we have any statistics on real-life "n" values?
My original suggestion wasn't based on performance issues. It was based on
the notion of tuples-as-records and lists-as-arrays. Raymond had originally
gone through the code and changed
for x in [1,2,3]:
to
for x in (1,2,3):
I suggested that since the standard library code is commonly used as an
example of basic Python principles (that's probably not the right word), it
should uphold that ideal tuple/list distinction. Raymond then translated
for x in [1,2,3]:
to
for x in frozenset([1,2,3]):
I'm unclear why the list in "for x in [1,2,3]" or "if x not in [1,2,3]"
can't fairly easily be recognized as a constant and just be placed in the
constants array. The bytecode would show n LOAD_CONST opcodes followed by
BUILD_LIST then either a COMPARE_OP (in the test case) or GET_ITER+FOR_ITER
(in the for loop case). I think the optimizer should be able to recognize
both constructs fairly easily.
I don't know if that would provide a performance increase or not. I was
after separation of functionality between tuples and lists.
Skip
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
