attached a prototype patch that avoids the memset of ob_item in PyTuple_New which is not necessary for the BUILD_TUPLE bytecode and PyTuple_Pack as these overwrite every entry in ob_item anyway.
This improves small tuple creation by about 5%.

It does this by adding a new internal function that does not use the memset loop and wrapping that in PyTuple_New that does it. _Pack and ceval call the internal function.
The patch still needs cleanup I don't know where the signature for ceval.c would best go. Does the internal function need to be hidden from the DSO?

microbenchmark, compiled with gcc-4.8.2 on ubuntu 14.04 amd64, default configure options:

import timeit
print(min(timeit.repeat("(a,)", setup="a = 1; b = 1", repeat=5, number=10**7)))
print(min(timeit.repeat("(a, b)", setup="a = 1; b = 1", repeat=5, number=10**7)))

before:
0.45767
0.52926

after:
0.42652
0.50122

larger tuples do not profit much as the loading is more expensive in comparison.

A 5% improvement on a micro-benchmark probably means 0% on real workloads. You could try to run the benchmarks suite at http://hg.python.org/benchmarks

I think this looks promising.

Don't worry too much about the modest timing improvement.  For the most part, we should almost always take steps to eliminate work that is known to be unnecessary.  The timings serve as a guide but it would be easy for us to get trapped in local minimums on a particular machine or compiler.

> avoid memset in small tuple creation

I don't understand this title because there is no call to memset() in the patch.

Can you try to modify PyTuple_New() to use memset() instead of a dummy loop?

Adding a _PyTuple_New() which doesn't initialize the memory doesn't seem safe to me.

You may try to allocate the tuple with PyObject_Calloc(), but when I tried on other types, it was slower than PyObject_Malloc() for sizes smaller than 1 MB.

Running the https://hg.python.org/benchmarks suite against this change (edited to not have the warning about PyTupleObject* vs PyObject* types) I see no repeatably significant benefits and one that is consistently a few percent slower no matter how many times I run it: nbody.

### nbody ###
Min: 0.226902 -> 0.236582: 1.04x slower
Avg: 0.231973 -> 0.238949: 1.03x slower
Significant (t=-11.98)
Stddev: 0.00507 -> 0.00286: 1.7751x smaller

That seems odd to me, but _might_ be related to the additional call overhead. Regardless, I don't think this patch is really an optimization.

right at best its probably too insignificant to really be worthwhile, closing.