meta_leap Are you truly telling me Godot's C++-based UDP networking is faster (or less "troubling") than Godot's C-side stdout/stdin pipes

It might be, depending on what actual i/o streams are abstracted away by stdin and stdout on your target system(s). Printing to console is not without cost either. There are also possible encoding issues. Try to benchmark it.

If you insist on using operating system inter-process communication, better to do it via proper named pipes, especially if exchanged data is plain binary bytes.

      xyz I'll check it out for sure. Still optimistic as I'm only targeting the usual-3 desktop OS kernels and their std pipes are likely to be on-par to named ones (sans the name "overhead"). But yeah good points for potential pitfalls to look out for. If When this ever gets so far as to become an installable offering for another's machine, that is 😁

      • xyz replied to this.

          meta_leap Also note that inter-process communication is always platform dependent, at least to a degree. Using a platform-agnostic network protocol can spare you any potential gotchas there. It's also better for future scalability - for example should you wish to port to another more exotic platform or expand the thing to communicate with remote machine(s).

          Even if mid level network protocol proves to be slower on a specific platform, I doubt the difference will be of any real significance if there is no need for high-volume frame-by-frame communication, as you stated is the case in the OP. So I don't see any reason to ditch the leisure and maintainability benefits of a network protocol.

          But looks like this is moving into premature optimization zone now. I'd go with UDP packet exchange for start and worry about alternatives when/if it starts to cause bottlenecks.