Hi, folks. I'm working on a POC: gRPC as a replacement for JNI.
Currently JNI is considered as bug-prone: - requires writing the code manually - specific JNI-knowledge required - possible threading and memory management issues The main concern about gRPC for me is performance: we need gRPC to work not too much slower compared to JNI (ideally even better). Another concern is disk footprint: for some reason share library having gRPC and libprotobuf (we tried to consume -lite) is about 2Mb per ABI which is too large. Please find the full code in my github repo <https://github.com/4ntoine/JniBenchmarking>. I've benchmarked it and here are my conclusions: - InProcess transport can't be used across languages - all other transports are significantly slower compared to pure JNI call (~25 *micro*seconds for JNI call vs. ~3-5 *milli*seconds for gRPC call) - disk footprint cost is pretty high Please find v1 of the research <https://drive.google.com/file/d/1Pqn7aOZ7GyEnegNUzwyl-_KnNxw70UhC/view?usp=sharing> and i'd love to know what you think about it. Are the conclusions expected? Did i do anything wrong/suboptimal? Can anything about gRPC or how i used it be improved (even with 3rd-party channels or smth)? Best, Anton. PS. I've find smth related to transport across the languages in this discussion <https://groups.google.com/g/grpc-io/c/G6MwxCu9jfY/m/fWr9vCR-AQAJ>. PS2. My SO question <https://stackoverflow.com/questions/65389428/how-to-connect-to-grpc-c-inprocesschannel-not-from-c> . PS3. I've already got some feedback from Eric but i'd love to have some discussion on it. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/ab049b77-5a51-4caf-9641-aeaa9c9a3e98n%40googlegroups.com.
