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

on Android _bootlocale on startup relies on too many library modules #72782

Closed
xdegaye mannequin opened this issue Nov 3, 2016 · 11 comments
Closed

on Android _bootlocale on startup relies on too many library modules #72782

xdegaye mannequin opened this issue Nov 3, 2016 · 11 comments
Assignees
Labels
3.7 (EOL) end of life interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage

Comments

@xdegaye
Copy link
Mannequin

xdegaye mannequin commented Nov 3, 2016

BPO 28596
Nosy @malemburg, @warsaw, @brettcannon, @rhettinger, @mdickinson, @ncoghlan, @orsenthil, @vstinner, @tiran, @benjaminp, @ezio-melotti, @merwok, @florentx, @xdegaye, @ericsnowcurrently, @yan12125
Files
  • android-locale-utf8.patch
  • android-locale-utf8.patch: Patch version 2
  • android-locale-utf8.patch: Patch version 3
  • android-locale-utf8.patch: Patch version 4
  • android-locale-utf8.patch: Patch version 5
  • 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 = 'https://github.com/xdegaye'
    closed_at = <Date 2016-12-17.08:39:00.025>
    created_at = <Date 2016-11-03.09:48:40.081>
    labels = ['interpreter-core', '3.7', 'performance']
    title = 'on Android _bootlocale on startup relies on too many library modules'
    updated_at = <Date 2017-03-31.23:33:26.684>
    user = 'https://github.com/xdegaye'

    bugs.python.org fields:

    activity = <Date 2017-03-31.23:33:26.684>
    actor = 'admin'
    assignee = 'xdegaye'
    closed = True
    closed_date = <Date 2016-12-17.08:39:00.025>
    closer = 'xdegaye'
    components = ['Interpreter Core']
    creation = <Date 2016-11-03.09:48:40.081>
    creator = 'xdegaye'
    dependencies = []
    files = ['45535', '45537', '45751', '45759', '45785']
    hgrepos = []
    issue_num = 28596
    keywords = ['patch']
    message_count = 11.0
    messages = ['279981', '281131', '281153', '281170', '282339', '282386', '282481', '282505', '282616', '283472', '283475']
    nosy_count = 18.0
    nosy_names = ['lemburg', 'barry', 'brett.cannon', 'rhettinger', 'mark.dickinson', 'ncoghlan', 'orsenthil', 'vstinner', 'christian.heimes', 'benjamin.peterson', 'ezio.melotti', 'eric.araujo', 'Arfrever', 'flox', 'xdegaye', 'python-dev', 'eric.snow', 'yan12125']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'performance'
    url = 'https://bugs.python.org/issue28596'
    versions = ['Python 3.7']

    @xdegaye
    Copy link
    Mannequin Author

    xdegaye mannequin commented Nov 3, 2016

    Android does not have langinfo.h and this results in _bootlocale importing locale on startup (see bpo-26928).

    IMHO it is not acceptable to fallback to locale.py if CODESET is not available (in answer to Victor question in msg199367), because there are now two code paths to investigate weird bugs such as the one described by Antoine in bpo-9548. Also note that Android platforms have a slow processor and limited RAM size, so they would strongly benefit from a startup sequence avoiding the imports made by the locale module. Since there is already a _bootlocale module, what are now the objections to implement the patch Antoine has proposed in bpo-9548 ?

    Nosying people from bpo-9548.

    @xdegaye xdegaye mannequin added type-bug An unexpected behavior, bug, or error 3.7 (EOL) end of life interpreter-core (Objects, Python, Grammar, and Parser dirs) labels Nov 3, 2016
    @yan12125
    Copy link
    Mannequin

    yan12125 mannequin commented Nov 18, 2016

    Here's my try: force UTF-8 on Android as explained in msg281110. sys.getfilesystemencoding() is already UTF-8 since bpo-22747.

    Testing:

    1. Starting up time 0.18~0.19s => 0.11~0.12s, on Android 6.0, ASUS ZE500KL (Qualcomm MSM8916 QuadCore 1.2GHz)
    2. test_site passes

    @yan12125
    Copy link
    Mannequin

    yan12125 mannequin commented Nov 18, 2016

    Version 2 - use sys.implementation._multiarch to determine whether it's Android or not

    @vstinner
    Copy link
    Member

    I created the issue bpo-28740: Add sys.getandroidapilevel().

    @xdegaye xdegaye mannequin self-assigned this Dec 3, 2016
    @xdegaye xdegaye mannequin added performance Performance or resource usage and removed type-bug An unexpected behavior, bug, or error labels Dec 3, 2016
    @yan12125
    Copy link
    Mannequin

    yan12125 mannequin commented Dec 4, 2016

    Patch version 3, using sys.getandroidapilevel()

    @yan12125
    Copy link
    Mannequin

    yan12125 mannequin commented Dec 5, 2016

    Thanks Victor. Here's new patch, which uses hasattr

    @vstinner
    Copy link
    Member

    vstinner commented Dec 5, 2016

    android-locale-utf8.patch LGTM, but I added minor comments on the review.

    I would prefer to let Xavier merges this one, since he can test it.

    @xdegaye
    Copy link
    Mannequin Author

    xdegaye mannequin commented Dec 6, 2016

    This is a performance issue. I will look at it shortly.

    @yan12125
    Copy link
    Mannequin

    yan12125 mannequin commented Dec 7, 2016

    Patch version 5, updated comments. Thanks for all of those feedbacks :)

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Dec 17, 2016

    New changeset 1756beed417c by Xavier de Gaye in branch 'default':
    Issue bpo-28596: The preferred encoding is UTF-8 on Android.
    https://hg.python.org/cpython/rev/1756beed417c

    @xdegaye
    Copy link
    Mannequin Author

    xdegaye mannequin commented Dec 17, 2016

    Closing the issue. Thanks for the patch Chi Hsuan Yen.

    @xdegaye xdegaye mannequin closed this as completed Dec 17, 2016
    @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.7 (EOL) end of life interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage
    Projects
    None yet
    Development

    No branches or pull requests

    1 participant