lupko commented on issue #43819: URL: https://github.com/apache/arrow/issues/43819#issuecomment-2312531489
@lidavidm , @felipecrv thanks for the info. that is an interesting pivot. As a heavy user of PyArrow & the Flight RPC infra within, I would like to raise few additional questions / concerns - especially when it comes to PyArrow. Sorry for longer text, I want to give you as much context as feasible. Its all in the area of the 'heavy lifting' APIs such as DoGet, DoPut and DoExchange. In the current state, where PyArrow wraps the C++ impl, it is possible to 'hand over' all the heavy lifting to C++ - all of the reading/writing happens end-to-end there: the python interpreter and its GIL is almost completely out of the picture. _Our server code / data services take advantage of current PyArrow/Flight architecture in order to reduce interpreter overhead and thread congestion on GIL. For example in DoGet, where necessary, we make our own RecordBatchReader implementations in C++ (with Cython bindings) so that the code can create RBR and then hand it over in `RecordBatchStream` as result -> when sending data, everything is done outside of interpreter. For another example, also in DoGet area, we create Acero pipeline that takes source data reader on input, and produces results into new RBR (with backpressure applied) - and again we hand over that RBR as result of do_get via `RecordBatchStream`. We do analogous things during DoPut - where the reader of input data is processed in our custom Cython extension, outside of Python. In other words, Python code never iterates over the data, never touches the data (with one or two corner-case exceptional scenarios) In essence, we use PyArrow and its Flight RPC so that Python code does 'high level decisions' and the heavy lifting is offloaded the underlying C++ code - with all the performance benefit it brings. That is where I see a big non-functional value of the existing design - e.g. all that wrapping and layers are not 'useless'._ --- So the **first** question... will these types of optimizations be possible in the setup you are thinking about? AFAIK the Python's grpcio also uses Cython to bridge to C++ impl but I do not see anywhere / unsure whether these types of optimizations would be possible there. **Second** question relates also to the bi-di streaming operations. As I gather (maybe incorrectly? I have seen something in code but have not studied 100%) there is currently a sort of 'contract' set between client and server - outside of just the proto files/service definitions. E.g. who closes which side of the stream first and thus signals to the other side they should do something. Proceeding in correct order is essential it seems. So .. if i'm not hallucinating all this, how will this be tackled? Extra 'grpc implementation' hints that every author has to implement in order for the server to play well with other clients in the ecosystem? **Third** question is a timeframe one. I gather that you are now still experimenting with the approach - so it may take some time for some things to actually land right? Any timeframe there? And also, what happens if/when this new approach goes live? Are you anticipating to deprecate & later throw away all the 'old stuff'? :) I'm asking these because we rely on PyArrow Flight RPC quite heavily so any radical changes in the area will have non-trivial impact - so having some rough timeframe would be good to have asap :) Thanks for your time. P.S: as I gather you are still in experimentation phase, I will proceed with the PR on the TryCancel stuff sometime later this week or next week. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
