Visitar URL original
The bytecode for f-string formatting is inefficient. · Issue #77273 · python/cpython · GitHub
Skip to content

The bytecode for f-string formatting is inefficient. #77273

Closed
Closed
The bytecode for f-string formatting is inefficient.#77273
Labels
3.12only security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)performancePerformance or resource usage

Description

@markshannon
markshannon
opened on Mar 17, 2018
BPO 33092
Nosy @pitrou, @ericvsmith, @markshannon, @serhiy-storchaka
PRs
  • gh-77273: Better bytecodes for f-strings #6132
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
closed_at = None
created_at = <Date 2018-03-17.12:33:10.371>
labels = ['interpreter-core', '3.8', 'performance']
title = 'The bytecode for f-string formatting is inefficient.'
updated_at = <Date 2021-08-26.14:31:11.408>
user = 'https://github.com/markshannon'

    bugs.python.org fields:

    activity = <Date 2021-08-26.14:31:11.408>
actor = 'Mark.Shannon'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2018-03-17.12:33:10.371>
creator = 'Mark.Shannon'
dependencies = []
files = []
hgrepos = []
issue_num = 33092
keywords = ['patch']
message_count = 7.0
messages = ['314000', '314001', '314004', '314312', '314317', '322379', '400348']
nosy_count = 4.0
nosy_names = ['pitrou', 'eric.smith', 'Mark.Shannon', 'serhiy.storchaka']
pr_nums = ['6132']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'performance'
url = 'https://bugs.python.org/issue33092'
versions = ['Python 3.8']

    Activity

    1. markshannon commented on Mar 17, 2018

      @markshannon
      markshannon
      on Mar 17, 2018
      MemberAuthor

      f-string expressions can be formatted in four ways:
      with or without a conversion
      and
      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
      FORMAT_SIMPLE
      FORMAT_WITH_SPEC

      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.

    2. markshannon
      added
      3.8 (EOL)end of life
      interpreter-core(Objects, Python, Grammar, and Parser dirs)
      performancePerformance or resource usage
      on Mar 17, 2018

    3. ericvsmith commented on Mar 17, 2018

      @ericvsmith
      ericvsmith
      on Mar 17, 2018
      Member

      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.

    4. markshannon commented on Mar 17, 2018

      @markshannon
      markshannon
      on Mar 17, 2018
      MemberAuthor

      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.

    5. pitrou commented on Mar 23, 2018

      @pitrou
      pitrou
      on Mar 23, 2018
      Member

      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 :-)

    6. serhiy-storchaka commented on Mar 23, 2018

      @serhiy-storchaka
      serhiy-storchaka
      on Mar 23, 2018
      Member

      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.

    7. taleinat commented on Jul 25, 2018

      @taleinat
      taleinat
      on Jul 25, 2018
      Contributor

      Mark, since you have a working version of this, perhaps you can supply some performance benchmark results to help in making a decision?

    8. markshannon commented on Aug 26, 2021

      @markshannon
      markshannon
      on Aug 26, 2021
      MemberAuthor

      No significant change in performance https://gist.github.com/markshannon/34a780d65e69b5a573a83f3fdb0139aa

      I think this merely indicates that there are little to no f-strings in the pyperformance benchmark suite.

    9. ezio-melotti
      transferred this issue fromon Apr 10, 2022
    10. iritkatriel
      added
      3.12only security fixes
      and removed
      3.8 (EOL)end of life
      on Sep 1, 2022

    11. iritkatriel commented on Sep 1, 2022

      @iritkatriel
      iritkatriel
      on Sep 1, 2022
      Member

      @markshannon are you still interested in this? should we repeat the measurements with benchmarks that have more f-strings?

    12. markshannon
      added a commit that references this issue on Jun 14, 2023

      GH-77273: Better bytecodes for f-strings (GH-6132)

      1d857da
    13. carljm
      added a commit that references this issue on Jun 15, 2023

      Merge branch 'main' into modulelocals

      166aca9

    14. hauntsaninja commented on Sep 7, 2023

      @hauntsaninja
      hauntsaninja
      on Sep 7, 2023
      Contributor

      Looks like this was implemented in #6132, thanks all!

    15. hauntsaninja
      closed this as completedon Sep 7, 2023
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      3.12only security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)performancePerformance or resource usage

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions