-----Original Message----- From: python-dev-bounces+kristjan=ccpgames....@python.org [mailto:python-dev-bounces+kristjan=ccpgames....@python.org] On Behalf Of Antoine Pitrou Sent: Wednesday, October 27, 2010 18:36
>Here are micro-benchmarks under 3.2: > $ ./python -m timeit -s "x = b'x'*10000" "x[:100]" > 10000000 loops, best of 3: 0.134 usec per loop > $ ./python -m timeit -s "x = memoryview(b'x'*10000)" "x[:100]" > 10000000 loops, best of 3: 0.151 usec per loop That's weird. The greedy slice needs two memory allocations. One for the ByteArray object itself, one for its cargo. In total, more that 100 bytes. In contrast, creating the MemoryView object requires only one allocation of a few dozen bytes. The performance difference must come from some other weird overhead, such as initializing the new MemoryView object. This would be pretty cool to profile using a proper profiler. I'll see what my MS tools can come up with. Meanwhile, a patch is in the tracker: http://bugs.python.org/issue10212 Also this: http://bugs.python.org/issue10211 There is a precedent of treating the failure to accept the Py_buffer interface as bugs in 2.7. After all, this is a supported internal buffer. See for example: http://bugs.python.org/issue8104 K _______________________________________________ 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
