GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Faster ASCII and possibly UTF-8 decoding of text files with TextIOWrapper · Issue #101289 · python/cpython

Faster ASCII and possibly UTF-8 decoding of text files with TextIOWrapper #101289

New issue
Copy link
New issue
Copy link
Closed as not planned
Closed as not planned
Faster ASCII and possibly UTF-8 decoding of text files with TextIOWrapper#101289
Copy link
Labels
performancePerformance or resource usagePerformance or resource usagetopic-IOtype-featureA feature request or enhancementA feature request or enhancement

Description

@rhpvorderman
rhpvorderman
opened on Jan 24, 2023
Issue body actions

Feature or enhancement

Do an ASCII check on the entire buffer for TextIOWrapper and safe this as a variable. Such as self->buffer_is_ascii. Use this informed knowledge to create strings more quickly.

Pitch

PyUnicode_Decode* functions perform a check what the maximum character is for the data. For instance PyUnicode_DecodeLatin1 still scans and if the string is actually ASCII an ASCII string is made. A similar process happens when using TextIOWrapper to decode a text file.

However in the ASCII case, all characters are ASCII. In the UTF8 case, possibly all characters are ASCII. In that case a PyUnicode_New call to initialize an ASCII string and a simple memcpy of the data is much faster than the alternative. This is utilized in the dnaio parser for FASTQ files.

The following code runs at 20GB/s https://github.com/rhpvorderman/ascii-check/blob/main/ascii_check.h#L41 and is therefore almost cost-free when running on io.DEFAULT_BUFFER_SIZE chunks (8kb IIRC). Also a SSE2 implementation is provided in the same repository.

After this step is performed a lot of the translation and decoding can in fact be skipped if the data turns out to be ASCII. Since UTF-8 files are quite common, this can turn out to be a real-world performance benefit.

Activity

  1. rhpvorderman
    added
    type-featureA feature request or enhancementA feature request or enhancement
    on Jan 24, 2023
  2. Fidget-Spinner
    added
    performancePerformance or resource usagePerformance or resource usage
    on Jan 25, 2023
  3. serhiy-storchaka
    added
    topic-IO
    on Feb 7, 2024
  4. serhiy-storchaka
    added this to Codecs and encodings issueson Mar 1, 2024
  5. rhpvorderman commented on Sep 16, 2024

    @rhpvorderman
    rhpvorderman
    on Sep 16, 2024
    ContributorAuthor
    More actions

    I made a PR #120212 but the added code complexity was not deemed worth the minor speed increase.

  6. rhpvorderman
    closed this as completedon Sep 16, 2024
  7. github-project-automation
    moved this to Done in Codecs and encodings issueson Sep 16, 2024
  8. terryjreedy
    closed this as not plannedon Sep 16, 2024
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

    performancePerformance or resource usagePerformance or resource usagetopic-IOtype-featureA feature request or enhancementA feature request or enhancement

    Projects

    • Codecs and encodings issues
      Status
      Done
      Show more project fields

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    You are visitor 01402503 — GeezerVison does not store the pages you look up.
    Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.