On Oct 23, 2019, at 22:45, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > > Andrew Barnert via Python-ideas wrote: >> Someone earlier in this thread said we could optimize calling split on a >> string literal, just as we can and do optimize iterating over a list literal >> in a for statement. >> The counter argument—which I thought you were adding onto—is that this would >> be bad because it would make people write bad code for older/alternative >> Pythons. > > There's a precedent for this kind of thing -- there's an optimisation > for repeatedly concatenating onto a string in some circumstances, even > though building a list and joining it is recommended if you want > guaranteed good performance. So the fact that it wouldn't apply to all > versions and implementations of Python shouldn't really matter. > > I'm not sure how much it would really help, though. Lists being > mutable, it would have to build a new list every time,
Sure, but a small number of LOAD_CONSTs and a BUILD_LIST has to be faster than 1 LOAD_CONST and a call to the split method. From testing some different random examples, the split takes anywhere from 1.8x to 3.9x as long, and I assume with longer element strings it would be even more of a difference. I still doubt this ever occurs anywhere near a bottleneck in real-life code—but if it did, it seems like the optimization would be worth it. (Assuming a better micro-benchmark verifies my quick&dirty test.) _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4NAWS4DQDI6OLJL3LZXRMQ3AG52G47ZR/ Code of Conduct: http://python.org/psf/codeofconduct/
