Do we still need `asciilib` for better performance?

Open
#98,229 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Refactor
Clarity
Needs clarification
Activity status
Stale
Tech stack
c, python
Domain
performance

Research direction

Start with the asciilib_count calls used by unicode_count and the asciilib_rsplit_whitespace path, comparing ASCII and non-ASCII inputs across Windows, macOS, and Linux. Measure the affected Python methods and C API functions with short and long strings; done means producing enough benchmark evidence to decide whether the calls should remain or be removed.

Written by the indexing model from the issue text.

Description

interpreter-core performance type-feature

Feature or enhancement

asciilib was introduced in https://github.com/python/cpython/commit/c3cec7868bf1019c0987f1e9aadb56d73fa93d61 as a performance feature for ascii strings.

11 years have passed since then.

While working on https://github.com/python/cpython/pull/98025 we with @vstinner experimented on unicode_count with and without asciilib_count calls.

Results were clear: it does not bring any benefits on our benchmarks.
And this commit was made: https://github.com/python/cpython/commit/df3a6d9beb8a7a3fe87a6d4126384fd3e0213853

Later, while working on https://github.com/python/cpython/pull/98228 I've noticed that asciilib_rsplit_whitespace also does not provide significant performance gains on my platform and my simple data input.

So, maybe this should be analyzed deeply?

Pitch

  • I think that these calls should be further investigated: do we really need this?
  • We should come up with better data to make a final decision, including:
    • What pytohn methods / c-api functions are affected?
    • Short and long ascii / non-ascii strings (because this check slows down all non-ascii strings by calling extra PyUnicode_IS_ASCII(str)
    • Windows / MacOS / Linux platforms, maybe the results will be different

I don't have access to Windows, but I can do the research for other platforms.

If it does not provide any performance benefits, it should be removed.

Dominant language
Python
Stars
77.2k
Forks
36k
Avg merge
1d 9h
Merged PRs (30d)
558

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from python/cpython

All issues in python/cpython

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.