Title: The bytecode for f-string formatting is inefficient.
Type: performance Stage: patch review
Components: Interpreter Core Versions: Python 3.8
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Mark.Shannon, eric.smith, pitrou, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2018-03-17 12:33 by Mark.Shannon, last changed 2021-08-26 14:31 by Mark.Shannon.

Pull Requests
URL Status Linked Edit
PR 6132 open Mark.Shannon, 2018-03-17 13:02
Messages (7)
msg314000 - (view) Author: Mark Shannon (Mark.Shannon) * (Python committer) Date: 2018-03-17 12:33
f-string expressions can be formatted in four ways:
   with or without a conversion
   with or without a format specifier

Rather than have one bytecode that parses the opcode argument at runtime it would be more efficient and produce a cleaner interpreter for the compiler to produce one or two bytecode as required.
The bytecodes should be:
  CONVERT_VALUE convert_fn

For simple format expressions with no conversion or format specifier,
which make up about 3/4 of all format expressions in the standard library, just the bytecode FORMAT_SIMPLE need be executed.
msg314001 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2018-03-17 12:40
Would this change really have a performance impact? Not saying it wouldn't, but if we're going to add bytecodes we should know the answer in advance.
msg314004 - (view) Author: Mark Shannon (Mark.Shannon) * (Python committer) Date: 2018-03-17 13:05
Even if doesn't speed things up by a significant amount, I would suggest that a simper interpreter with smaller, simpler bytecodes is a worthy goal in itself.
msg314312 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2018-03-23 16:32
>  I would suggest that a simper interpreter with smaller, simpler bytecodes is a worthy goal in itself.

+1 from me.  Though I'm curious about performance changes as well :-)
msg314317 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-03-23 17:18
I wouldn't say this more efficient. Instead one instruction you would need to execute two instructions.

If I implemented f-string formatting I would add four simple opcodes for str(), repr(), ascii() and format(). But Eric merged them all in the single opcode with complex argument. While this looks more complicated and less extensible, it is more efficient.
msg322379 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2018-07-25 17:57
Mark, since you have a working version of this, perhaps you can supply some performance benchmark results to help in making a decision?
msg400348 - (view) Author: Mark Shannon (Mark.Shannon) * (Python committer) Date: 2021-08-26 14:31
No significant change in performance

I think this merely indicates that there are little to no f-strings in the pyperformance benchmark suite.
Date User Action Args
2021-08-26 14:31:11Mark.Shannonsetmessages: + msg400348
2018-07-25 17:57:39taleinatsetnosy: - taleinat
2018-07-25 17:57:24taleinatsetnosy: + taleinat
messages: + msg322379
2018-03-23 17:18:04serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg314317
2018-03-23 16:32:47pitrousetnosy: + pitrou
messages: + msg314312
2018-03-17 13:05:29Mark.Shannonsetmessages: + msg314004
2018-03-17 13:02:10Mark.Shannonsetkeywords: + patch
stage: patch review
pull_requests: + pull_request5893
2018-03-17 12:40:08eric.smithsetnosy: + eric.smith
messages: + msg314001
2018-03-17 12:33:10Mark.Shannoncreate