feat : ABI upgrade from abi_stabby to stabby since abi_stable is no longer maintained#21030
feat : ABI upgrade from abi_stabby to stabby since abi_stable is no longer maintained#21030coderfender wants to merge 37 commits intoapache:mainfrom
Conversation
|
Linking Tim's PR here #21025 |
|
|
One of the things I've been thinking about here is doing some scale testing of performance, which I haven't done on the FFI crate really. I was thinking we could do something along the lines of using https://github.com/datafusion-contrib/datafusion-tpch to generate table providers at different scale factors. Then it would seem we could have a series of tests:
The thing I like about doing this is that we would be able to see the impacts of each of the layers between the code, ideally going from 2->3 having near zero impact. For such a test I would think about setting up a stream, reading in and dumping the data as fast as possible. Since this is orthogonal to the actual FFI work you're proposing I might try setting this up on a test repo. |
7dea35a to
9834a59
Compare
|
Merged with main and see some referenced older package. Working on fixing it to use |
|
Updated cargo format , changed table_provider_module to use the direct function pointer call instead of accessor method pattern used in abi_stable |
70a5478 to
d6194b8
Compare
|
Testing python bindings now with the new ABI |
|
The df python bindings rendered through new stabby implementations seem to be working on my local machine |
timsaucer
left a comment
There was a problem hiding this comment.
Really nice work on this. I've put in a few questions. I think it's really great that the vast majority of the changes are pretty simple and have 1-1 replacement.
|
thank you for the comments @timsaucer . I will work on the comments and push a commit shortly |
d63326d to
48926f9
Compare
|
Thank you for the update @timsaucer . Let me go ahead and update the docs to better reflect our approach here |
| pub type FFIResult<T> = RResult<T, RString>; | ||
| /// back. These are converted back and forth using the `df_result`, `sresult`, | ||
| /// and `sresult_return` macros. | ||
| pub type FFIResult<T> = FFI_Result<T, SString>; |
There was a problem hiding this comment.
Having both a FFIResult<T> and a FFI_Result<T, SString> is confusing. Can we merge down to one?
There was a problem hiding this comment.
Great point ! sure
There was a problem hiding this comment.
Given that there is only String based error usage across migration, we might not even need <T,E> and could consolidate this into just FFIResult<T>
There was a problem hiding this comment.
Yes, FFI_Result<T> to be consistent with the rest of the repo
There was a problem hiding this comment.
Absolutely! I made changes to have one result used and exposed outside
a4e5903 to
71f1fde
Compare
0ea3355 to
287ef29
Compare
8ae10c0 to
1aa4823
Compare
|
CI is now green |
|
|
Updated |
timsaucer
left a comment
There was a problem hiding this comment.
Looking very good. Minor recommendation since this wasn't a reason for using the repr(c) vs macro but rather an outcome of the decision.
|
Thank you . I updated the trait names per review comments |
|
Looks like a couple of accidentally commited json files? |
|
Thank you for the review . It seems like some of benchmark JSONs from my other pr got pulled in here. Let me remove them and update here |
5e2f303 to
99f089c
Compare
Which issue does this PR close?
generational-arenafrom project #20863Rationale for this change
What changes are included in this PR?
RVec->stabby::vec::VecRString->stabby::string::StringFFI_OptionandFFI_Resulttypes since we have raw pointers and self referential pointers which can't implementIStabletrait needed for stabbymacros: rresult→sresult,rresult_return→sresult_returnAre these changes tested?
Yes . With df python bindings on DF 52 release
Are there any user-facing changes?