New submission from Antti Haapala:
I benchmarked some f'' strings against .format, and surprisingly f'' was slower
than .format in about all the simple cases I could think of. I guess this is
because f'' strings implicitly use `''.join([])`.
The byte code for f'foo is {foo}' currently is
1 0 LOAD_CONST 1 ('')
3 LOAD_ATTR 0 (join)
6 LOAD_CONST 2 ('foo is ')
9 LOAD_GLOBAL 1 (foo)
12 FORMAT_VALUE 0
15 BUILD_LIST 2
18 CALL_FUNCTION 1 (1 positional, 0 keyword pair)
It was mentioned here https://bugs.python.org/issue24965 but since I came up
with the idea when inspecting this, I'd propose again here that a new opcode be
added for f'' strings - BUILD_STRING n, with which f'foo is {foo}' could be
compiled to
0 LOAD_CONST 2 ('foo is ')
3 LOAD_GLOBAL 1 (foo)
6 FORMAT_VALUE 0
9 BUILD_STRING 2
instead. Internally this wouldn't even need to call `PyUnicode_Join`, but
instead `seplen == 0` case could be refactored into a separate function. Not
only with this is it possible to know the length of the string, but also the
number of string components are already known, so it'd be possible to build a
tuple fast from the values on stack.
And that way people doing micro benchmarks would find out that the new Python
3.6 feature would not only look nice but also be a way to write
better-performing code.
----------
components: Interpreter Core
messages: 266016
nosy: ztane
priority: normal
severity: normal
status: open
title: Make f'' strings faster than .format: BUILD_STRING opcode?
type: enhancement
versions: Python 3.6
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue27078>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
