Sorry, I didn't check your implementation, but did you consider to reuse existing structseq type to implement namedtuple? https://bugs.python.org/issue28638#msg298499 Last time I ran a microbenchmark, structseq was 1.9x faster than namedtuple to get an attribute by name.

In the meanwhile, I removed property_descr_get() micro-optimization because it wasn't correct and caused 3 different crashed, bpo-30156, commit e972c13. So I get that structseq is now even faster than namedtuple to get an attribute :-)

Sorry, I didn't check your implementation, but did you consider to reuse existing structseq type to implement namedtuple? https://bugs.python.org/issue28638#msg298499 Last time I ran a microbenchmark, structseq was 1.9x faster than namedtuple to get an attribute by name.

Hummm I did not consider this, but that will involve more significant and fundamental changes than this Pull Request. Also, apparently there is this issue that Josh Rosenberg ran into when implementing the idea. I am happy to give it a go if people agree that is a good idea :) But I think this we can start with this Pull Request as is simpler and it gives some immediate speedup.

You do not need a subclass of property. You need just a descriptor.

Look also at __slots__ implementation.

@serhiy-storchaka Thanks! I will take a look into that. Independently, if we don't move the property object to the header file, is not possible to subclass property in C. What do you think we should do with that?

Try to make constructor arguments positional-only and repeat benchmarks for creating a namedtuple type. I think this can save several percents of creation time.

@serhiy-storchaka Here are the results (commit e5bca1d):

import perf

runner = perf.Runner()
runner.timeit("collections.namedtuple('A','x')", 
stmt="collections.namedtuple('A','x')", 
setup="import collections")

❯ ./python -m perf compare_to  ../cpython_baseline/old_creation.json new_creation.json
Mean +- std dev: [old_creation] 107 us +- 3 us -> [new_creation] 103 us +- 2 us: 1.03x faster (-4%)

This patch looks great. Thanks for the effort to get this done :-)

Before this gets committed, please make a couple of improvements.

1. The _tuplegetter() API needs to more fully emulate property():

>>> set(dir(property)) - set(dir(_tuplegetter))
{'__delete__', 'fdel', 'deleter', '__isabstractmethod__', 'setter', '__set__', 'getter', 'fget', 'fset'}

Part of the reason is that we want tuplegetter() to be a drop in substitute, supporting whatever interactions users have had with it before now (this is an old API). Another reason is that tuplegetter() needs to be recognized as a data descriptor so that its docstrings show-up in the output of help().

Formerly, running >>> help(namedtuple('Point', ['x', 'y'])(10, 20)) would produce:

 |  ----------------------------------------------------------------------
 |  Data descriptors defined here:
 |  
 |  x
 |      Alias for field number 0
 |  
 |  y
 |      Alias for field number 1

Now we get:

 |  Methods defined here:
 |
 |  x = <_collections._tuplegetter object>
 |  y = <_collections._tuplegetter object>

2. The code in tuplegetterdescr_get can be made tighter by using PyTuple_GET_SIZE() and PyTuple_GET_ITEM() instead of PyTuple_GetItem(). That saves the function call overhead and a redundant duplicate PyTuple_Check (the second check is 100% branch predictable which is good, but still incurs two chained memory accesses).

In running timings, we should not only benchmark 1.6x to 2.5 improvement, but also compare against regular attribute access to an instance of a class that defines __slots__. Ideally tuplegetter() should be almost as fast as member objects since both do almost exactly the same work (indexing into a tuple should be only slightly slower than into slots).

To be recognized as a data descriptor tuplegetter needs to implement __set__.

I do not think that _tuplegetter should fully emulate property. It is enough if implement the common API of properties and data descriptors.

>>> sorted(set(dir(int.numerator)) - set(dir(_tuplegetter)))
['__delete__', '__name__', '__objclass__', '__qualname__', '__set__']
>>> class A: __slots__ = 'x'
... 
>>> sorted(set(dir(A.x)) - set(dir(_tuplegetter)))
['__delete__', '__name__', '__objclass__', '__qualname__', '__set__']

@rhettinger @serhiy-storchaka I am not sure what is the best path to follow. To make this PR simpler, what do you think about just reverting commit 1e14509 so tuplegetter inherits from property setting all the attributes. This "emulates" property but I cannot see any obvious downside and it makes the implementation much cleaner and (IMHO) maintainable. Manually implementing all the property methods here seems to me like raising a lot the maintenance burden, without mentioning future divergence with property.

@serhiy-storchaka Although tuplegetter would be fine just implementing the common API of data descriptors, people may be using the old properties in the namedtuple directly, accessing some particular fields that only properties have, so not implementing them may be a regression, right?

I do not see sense in full emulating a property, and in any case your past versions did not do this.

Attributes setter and deleter are used only for defining the setter and the deleter in the class definition. _tuplegetter will not be used in such way.

__isabstractmethod__ does not make sense since _tuplegetter is not abstract.

fget, fset and fdel were not provided. In any case the user should not depend on such implementation detail. For getting a getter for the specific attribute they should use operator.attrgetter or trivial lambda.

We are at the pre-alpha stage. If some code will be broken by this change, we have enough time to fix it.

@serhiy-storchaka So you propose to implement:

['__delete__', '__name__', '__objclass__', '__qualname__', '__set__']

Is that correct?

Try to implement just __set__ and __delete__. If this is not enough for pydoc, implement more.

After db3ffcd:

>>> from collections import namedtuple
>>> help(namedtuple('Point', ['x', 'y'])(10, 20))

|  Data descriptors defined here:
|
|  x
|      Alias for field number 0
|
|  y
|      Alias for field number 1
|

>>> set(dir(property)) - set(dir(_tuplegetter))
{'fget', 'deleter', '__isabstractmethod__', 'getter', 'setter', 'fdel', 'fset'}

Benchmark agains a class definning __slots__ and tuples:

import perf

runner = perf.Runner()

runner.timeit("namedtuple",
        stmt="a.x",
        setup="""\
import collections
a = collections.namedtuple('A', ['x'])(3)
""")

runner.timeit("slots",
        stmt="b.x",
        setup="""\
class B:
    __slots__ = ("x",)

    def __init__(self, x):
        self.x = x
b = B(3)
""")

runner.timeit("tuple",
        stmt="b[0]",
        setup="""\
b = (3,)
""")

Results (no PGO):

./python ../experiment.py
.....................
namedtuple: Mean +- std dev: 34.7 ns +- 0.6 ns
.....................
slots: Mean +- std dev: 38.3 ns +- 1.8 ns
.....................
tuple: Mean +- std dev: 34.6 ns +- 0.2 ns

It turns that the latest _tuplegetter is 8% faster than __slots__ and basically the same as the tuple.

I ran some experiments regarding the inlining of PyTuple_GetItem and even without PGO is unoticeable under -O3 optimization. The x86 for the function call diff is:

        push    rbp
        mov     rbp, rsp
        mov     DWORD PTR [rbp-4], edi
        ...
        cmpq❘---%rdx, %rsi
        cmpq❘---%rax, 32(%rsi)

The two cmpq are smashed by the branch predictor and the stack allocation (the push and the two movs and subsequent) are almost negligible as the stack of tuplegetterdescr_get is reused. On the other hand, under O2 and less this changes and you can notice a small jitter in the benchmarks, so I think is a good idea to inline the call to PyTuple_GetItem as @rhettinger recommended.

FWIW, my timings show a significant improvement (more than 2x) and that named tuple attribute access is now on-par with access to member objects created by _slots_.

Nice work.

@rhettinger: Please replace # with GH- in the commit message next time. Thanks!