8000 Improve perfomance of UUID.hex and UUID.__str__ by using bytes.hex() · Issue #131196 · python/cpython · GitHub
[go: up one dir, main page]

Skip to content

Improve perfomance of UUID.hex and UUID.__str__ by using bytes.hex() #131196

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

Closed
booqoffsky opened this issue Mar 13, 2025 · 4 comments
Closed

Improve perfomance of UUID.hex and UUID.__str__ by using bytes.hex() #131196

booqoffsky opened this issue Mar 13, 2025 · 4 comments
Labels
performance Performance or resource usage stdlib Python modules in the Lib dir type-feature A feature request or enhancement

Comments

@booqoffsky
Copy link
Contributor
booqoffsky commented Mar 13, 2025

Feature or enhancement

Proposal:

In my tests, using bytes.hex() speeds up calling the UUID.hex property.

Additionally, using the hex property and f-strings also provides some speedup in calling uuid.UUID.str.

import uuid

uuids = [uuid.uuid4() for _ in range(100000)]

t1 = time.monotonic()
for u in uuids:
    u.hex
    # str(u)
t2 = time.monotonic()

print(t2 - t1)

Results before and after the fix:

hex
before: 0.021755493999989994
after:  0.01465080400066654 

str
before: 0.06381790500017814
after:  0.05134949700004654

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

Linked PRs

@booqoffsky booqoffsky added the type-feature A feature request or enhancement label Mar 13, 2025
@picnixz picnixz added the stdlib Python modules in the Lib dir label Mar 13, 2025
@picnixz
Copy link
Member
picnixz commented Mar 13, 2025

In other words, it boils down between whether '%032x' % self.int is faster or not than int->bytes conversion + bytes.hex(). So to really know whether it's faster or not, I would instead check the performances of "%032x" % self.int vs x = self.int.to_bytes(16); x.hex().

Now, I would appreciate benchmarks using timeit or pyperf instead of manual benchmarks. They are a bit more precise and stable (pyperf also shows the standard deviation which is kind of good to know). While it's a noticeable difference overall, we're actually only gaining 10^-8 for each call (since you're doing lots of objects). Finally, are the benchmarks performed on a DEBUG build, release build or optimized (PGO or PGO+LTO) build?

8000

@picnixz picnixz added the performance Performance or resource usage label Mar 13, 2025
@booqoffsky
Copy link
Contributor Author

Thanks for the answer!

This is how the interpreter was built:

./configure --enable-optimizations --with-lto
make -s -j8

Here are the measurement results:

nice -n 19 taskset -c 4 python3 -m pyperf timeit --affinity=4 --min-time 1 --processes 1 -s 'import uuid; u = uuid.uuid4()' '"%032x" % u.int'
# Mean +- std dev: 70.9 ns +- 0.2 ns
nice -n 19 taskset -c 4 python3 -m pyperf timeit --affinity=4 --min-time 1 --processes 1 -s 'import uuid; u = uuid.uuid4()' 'x = u.int.to_bytes(16); x.hex()'
# Mean +- std dev: 61.1 ns +- 0.3 ns

@picnixz
Copy link
Member
picnixz commented Mar 13, 2025

Mmh. The improvement is a small, but it's still a improvement I guesss. It's still > 10% improvement!

sobolevn pushed a commit that referenced this issue Mar 13, 2025
#131197)

Results before and after the fix:

```
hex
before: 0.021755493999989994
after:  0.01465080400066654 

str
before: 0.06381790500017814
after:  0.05134949700004654
```

Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
< 8000 /div>
@sobolevn
Copy link
Member

Thank you for the PR! Please, feel free to suggest more optimizations.

plashchynski pushed a commit to plashchynski/cpython that referenced this issue Mar 17, 2025
…by ~10% (python#131197)

Results before and after the fix:

```
hex
before: 0.021755493999989994
after:  0.01465080400066654 

str
before: 0.06381790500017814
after:  0.05134949700004654
```

Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
seehwan pushed a commit to seehwan/cpython that referenced this issue Apr 16, 2025
…by ~10% (python#131197)

Results before and after the fix:

```
hex
before: 0.021755493999989994
after:  0.01465080400066654 

str
before: 0.06381790500017814
after:  0.05134949700004654
```

Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance Performance or resource usage stdlib Python modules in the Lib dir type-feature A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

3 participants
0