Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize the empty set "literal" #77381

Closed
serhiy-storchaka opened this issue Apr 1, 2018 · 6 comments
Closed

Optimize the empty set "literal" #77381

serhiy-storchaka opened this issue Apr 1, 2018 · 6 comments
Labels
3.8 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage

Comments

@serhiy-storchaka
Copy link
Member

BPO 33200
Nosy @brettcannon, @mdickinson, @ncoghlan, @pitrou, @benjaminp, @serhiy-storchaka, @1st1, @MojoVampire
PRs
  • bpo-33200: Optimize bytecode for the empty set "literal". #6330
  • 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 = <Date 2018-04-09.16:35:29.582>
    created_at = <Date 2018-04-01.10:29:26.674>
    labels = ['interpreter-core', '3.8', 'performance']
    title = 'Optimize the empty set "literal"'
    updated_at = <Date 2018-04-09.16:35:29.581>
    user = 'https://github.com/serhiy-storchaka'

    bugs.python.org fields:

    activity = <Date 2018-04-09.16:35:29.581>
    actor = 'serhiy.storchaka'
    assignee = 'none'
    closed = True
    closed_date = <Date 2018-04-09.16:35:29.582>
    closer = 'serhiy.storchaka'
    components = ['Interpreter Core']
    creation = <Date 2018-04-01.10:29:26.674>
    creator = 'serhiy.storchaka'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 33200
    keywords = ['patch']
    message_count = 6.0
    messages = ['314769', '314771', '314772', '314790', '314849', '315138']
    nosy_count = 8.0
    nosy_names = ['brett.cannon', 'mark.dickinson', 'ncoghlan', 'pitrou', 'benjamin.peterson', 'serhiy.storchaka', 'yselivanov', 'josh.r']
    pr_nums = ['6330']
    priority = 'normal'
    resolution = 'rejected'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'performance'
    url = 'https://bugs.python.org/issue33200'
    versions = ['Python 3.8']

    @serhiy-storchaka
    Copy link
    Member Author

    The following PR optimizes bytecode for the empty set "literal": {*()}.

    Currently it is compiled to

    LOAD_CONST               0 (())
    BUILD_SET_UNPACK         1
    

    It will optimized to

    BUILD_SET                0
    
    $ ./python -m perf timeit --duplicate 1000 '{*()}'

    Unpatched: Mean +- std dev: 68.6 ns +- 1.1 ns
    Patched: Mean +- std dev: 31.8 ns +- 2.8 ns

    @serhiy-storchaka serhiy-storchaka added 3.8 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage labels Apr 1, 2018
    @mdickinson
    Copy link
    Member

    Does anyone seriously write "{*()}" instead of "set()"?

    @serhiy-storchaka
    Copy link
    Member Author

    Don't know. :-)

    Consider this as a 1st April egg.

    @pitrou
    Copy link
    Member

    pitrou commented Apr 1, 2018

    Does anyone seriously write "{*()}" instead of "set()"?

    It doesn't seem to be laughing to me.

    @MojoVampire
    Copy link
    Mannequin

    MojoVampire mannequin commented Apr 3, 2018

    I may have immediately latched onto this, dubbing it the "one-eyed monkey operator", the moment the generalized unpacking released.

    I always hated the lack of an empty set literal, and enjoyed having this exist just to fill that asymmetry with the other built-in collection types (that said, I never use it in production code, nor teach it in classes I run).

    @serhiy-storchaka
    Copy link
    Member Author

    Closed due to the lack of practical applications. Can be reopened if this idiom become popular.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.8 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage
    Projects
    None yet
    Development

    No branches or pull requests

    3 participants