[Python-Dev] default of returning None hurts performance?
Collin Winter
collinw at gmail.com
Tue Sep 1 00:28:29 CEST 2009
More information about the Python-Dev mailing list
Tue Sep 1 00:28:29 CEST 2009
- Previous message: [Python-Dev] default of returning None hurts performance?
- Next message: [Python-Dev] default of returning None hurts performance?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, Aug 31, 2009 at 3:07 PM, Gregory P. Smith<greg at krypto.org> wrote: > > > On Mon, Aug 31, 2009 at 2:20 PM, Antoine Pitrou <solipsis at pitrou.net> wrote: >> >> Gregory P. Smith <greg <at> krypto.org> writes: >> > >> > food for thought as noticed by a coworker who has been profiling some >> > hot code >> to optimize a library...If a function does not have a return statement we >> return >> None. Ironically this makes the foo2 function below faster than the bar2 >> function at least as measured using bytecode size >> >> I would be surprised if this "bytecode size" difference made a significant >> difference in runtimes, given that function call cost should dwarf the >> cumulated >> cost of POP_TOP and LOAD_CONST (two of the simplest opcodes you could >> find). >> > > the attached sample code repeatably shows that it makes a difference though > its really not much of one (2-3%). > > I was just wondering if a bytecode for a superinstruction of the common > sequence: > > 6 POP_TOP > 7 LOAD_CONST 0 (None) > 10 RETURN_VALUE > > might be worth it. I doubt it. You'd save a bit of stack manipulation, but since this will only appear at the end of a function, I'd be skeptical that this would make any macrobenchmarks (statistically) significantly faster. Collin Winter
- Previous message: [Python-Dev] default of returning None hurts performance?
- Next message: [Python-Dev] default of returning None hurts performance?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list