This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients barry, eric.smith, eric.snow, llllllllll, rhettinger
Date 2015-04-27.01:30:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1430098257.7.0.387560206792.issue23910@psf.upfronthosting.co.za>
In-reply-to
Content
If you have a chance, run a C profiler so we can see whether most of the time is being spent in an attribute lookup for the current property(itemgetter) approach versus your nt-indexer approach.  Without a profile, I have only my instincts that the overhead is a mix of indirections and function call overhead (both solveable by in-lining), and over-generalization for all PyObject_GetItem() (solvable by specialization to a tuple subclass), and variable length argument lists (solveable by using of PyTuple_New(1)).   

Ideally, I would like something that speeds-up broader swaths of the language and doesn't obfuscate the otherwise clean generated code.  ISTM that the C code for both property() and itemgetter() still have room to optimize the common case.
History
Date User Action Args
2015-04-27 01:30:57rhettingersetrecipients: + rhettinger, barry, eric.smith, eric.snow, llllllllll
2015-04-27 01:30:57rhettingersetmessageid: <1430098257.7.0.387560206792.issue23910@psf.upfronthosting.co.za>
2015-04-27 01:30:57rhettingerlinkissue23910 messages
2015-04-27 01:30:56rhettingercreate