-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Only used PyUnicode_Concat on unicode objects #3433
Conversation
Co-Authored-By: Stefan Behnel <stefan_ml@behnel.de>
Optimized inplace operations for bytes and unicode so that they're genuinely done in place if no-one else needs the object. This is what CPython tries to do (and was a string concatenation was a point where it significantly beat Cython at times) This only works if the types are known at compile time, so with unknown types CPython will still be faster in some cases
I've updated this to also optimize
|
This reverts commit 7d2608e.
Better if unicode concat is done with more settings of str_type
Yes, that seems worth doing on our side as well. Especially since 2-value f-strings are already replaced by a concatenation rather than joining because it's much faster. Making this even faster with this "hack" would be nice. |
Will be submitted separately |
Closes #3426
(I'm getting a segmentation fault on the fstring tests with the current master, which is making it difficult to run this through a thorough set of tests. It happens with and without this PR. I'm not sure where this is due to something being messed up on my side or a real bug, but I'll look into and report it separately. Just noting it here because it means I couldn't test this PR with with "runtest.py string")Caching issues to do with Cython.inline - I'd clearly ended up with a broken version cached - ignore