Description

markshannon

opened on Mar 17, 2018

Issue body actions

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

   on Mar 17, 2018

   MemberAuthor

   More actions

   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 lifeend of life

   interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)

   performancePerformance or resource usagePerformance or resource usage

   on Mar 17, 2018
3. ericvsmith commented on Mar 17, 2018

   

   ericvsmith

   on Mar 17, 2018

   Member

   More actions

   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

   on Mar 17, 2018

   MemberAuthor

   More actions

   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

   on Mar 23, 2018

   Member

   More actions

   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

   on Mar 23, 2018

   Member

   More actions

   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

   on Jul 25, 2018

   Contributor

   More actions

   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

   on Aug 26, 2021

   MemberAuthor

   More actions

   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 fixesonly security fixes

    and removed

    3.8 (EOL)end of lifeend of life

    on Sep 1, 2022
11. iritkatriel commented on Sep 1, 2022

    

    iritkatriel

    on Sep 1, 2022

    Member

    More actions

    @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

    on Sep 7, 2023

    Contributor

    More actions

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

    closed this as completedon Sep 7, 2023

Issue actions