Closed Huzaifa-MS closed 10 months ago
Hashicorp's go-plugin uses rpc implementations, every function call from current runtime to plugin need to pass through the network. so the performance is bad.
Golang's plugin use dl library open a .so library, so it is run faster. but it only run on the unix platform(e.g Linux/macosx). The .so library with full golang runtime, it needs a large amount of running memory, and golang forbids unload it.
My project loads golang objfiles and links them into a module. It reuses golang's runtime environment and allows to unload . It can run on the windows platform, but it only support x86/amd64/arm/arm64 architecture and doesn't support cgo.
If you don't care memory and don't use on the windows platform, you could use golang's plugin.
if you have more questions, reopen it
Thank you. I appreciate the time you took to reply. And sorry for not seeing it sooner.
Hi I am new to Golang and was researching the ecosystem for possible solution to implementing plugin architectures
I came across this article: https://www.reddit.com/r/golang/comments/kq1mvq/benchmarking_the_go_plugin_package_vs_other/
And your library was the best performance wise.
I was wondering what your take on is of the differences between your implementation vs Hashicorp's vs Standard plugins.
I don't understand why the pros and cons are there in the native vs rpc implementations. I can understand some of the performance impacts but features such as loading and unloading or the host crashes or memory sharing being limitations don't fully make sense to me.
Any comments?