experimental: owned objects API (alternative)#1304
Closed
davidhewitt wants to merge 9 commits intoPyO3:masterfrom
Closed
experimental: owned objects API (alternative)#1304davidhewitt wants to merge 9 commits intoPyO3:masterfrom
davidhewitt wants to merge 9 commits intoPyO3:masterfrom
Conversation
Member
|
Thank you for your big efforts in moving this forward! |
3 tasks
Member
Author
|
Sure thing, I pushed this as the Also opened #1308 to track merging that branch. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a fork of #1300 to use
PyAny<'py>as an owned pointer, as per discussion in that thread. ThePyOwnedtype is removed.I haven't implemented any design around
PyAnyRaw/PySend/Pyyet.Overall this design feels simpler to work with, so I plan to continue refining this branch over the original one.
The tests aren't all passing yet, but I did run a benchmark:
52,895 ns/iter (+/- 6,956)54,954 ns/iter (+/- 2,175)51,247 ns/iter (+/- 1,852)153,977 ns/iter (+/- 9,671)153,001 ns/iter (+/- 6,288)141,100 ns/iter (+/- 10,980)1,933,300 ns/iter (+/- 328,382)1,780,027 ns/iter (+/- 79,625)1,700,250 ns/iter (+/- 52,607)9,538,110 ns/iter (+/- 634,895)8,688,905 ns/iter (+/- 590,359)8,201,100 ns/iter (+/- 153,532)8,099,900 ns/iter (+/- 570,799)7,842,395 ns/iter (+/- 535,694)7,569,645 ns/iter (+/- 144,288)5,013,300 ns/iter (+/- 483,341)4,292,595 ns/iter (+/- 358,152)4,133,425 ns/iter (+/- 231,738)5,418,065 ns/iter (+/- 440,259)4,900,090 ns/iter (+/- 355,389)4,730,320 ns/iter (+/- 86,596)1,759,862 ns/iter (+/- 209,509)1,304,683 ns/iter (+/- 133,726)1,328,632 ns/iter (+/- 203,382)1,262,143 ns/iter (+/- 76,108)1,109,227 ns/iter (+/- 52,926)1,163,203 ns/iter (+/- 86,611)1,257,083 ns/iter (+/- 100,680)1,037,567 ns/iter (+/- 120,639)1,069,825 ns/iter (+/- 132,988)824,397 ns/iter (+/- 46,234)753,351 ns/iter (+/- 125,318)990,398 ns/iter (+/- 93,625)573,128 ns/iter (+/- 61,386)531,383 ns/iter (+/- 21,875)530,595 ns/iter (+/- 37,357)408,859 ns/iter (+/- 25,755)407,605 ns/iter (+/- 21,552)520,050 ns/iter (+/- 36,936)So the conclusion is that it's pretty much the same as the other branch. This is good; I was worried it would be slower!
The only slowdown compared to the other branch is that now tuple iteration / get_item must return an owned
PyAny.