[Python-Dev] Impact of Namedtuple on startup time (original) (raw)

Raymond Hettinger raymond.hettinger at gmail.com
Mon Jul 17 10:59:51 EDT 2017


On Jul 17, 2017, at 6:31 AM, Antoine Pitrou <antoine at python.org> wrote:

I think I understand well enough to say something intelligent…

While actual references to source are likely rare (certainly I’ve never used it), my understanding is that the way namedtuple works is to construct source, and then exec it to create the class. Once that is done, there is no significant saving to be had by throwing away the constructed source value.

There are considerable benefits to namedtuple being able to generate and match its own source.

I really don't want to throw away these benefits to save a couple of milliseconds. As Nick Coghlan recently posted, "Speed isn't everything, and it certainly isn't adequate justification for breaking public APIs that have been around for years."

FWIW, the template/exec implementation has had excellent benefits for maintainability making it very easy to fix and update. As other parts of Python have changed (limitations on number of arguments, what is allowed as an identifier, etc), it mostly automatically stays in sync with the rest of the language.

ISTM this issue is being pressed by micro-optimizers who are being very aggressive and not responding to actual user needs (it is more an invented issue than a real one). Named tuple has been around for a long time and users have been somewhat happy with it.

If someone truly cares about the exec time for a particular named tuple, the _source option makes it trivially easy to just replace the generator call with the expanded code in that particular circumstance.

Raymond

P.S. I'm fully supportive of Victor's efforts to build-out structseq to make it sufficiently expressive to do more of what collections.namedtuple() does. That is a perfectly reasonable path to optimization. We've wanted that for a long time and no one has had the spare clock cycles to make it come true.



More information about the Python-Dev mailing list