Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add sub_linker() API #2992

Open
bkolobara opened this issue Jun 16, 2021 · 4 comments
Open

Add sub_linker() API #2992

bkolobara opened this issue Jun 16, 2021 · 4 comments

Comments

@bkolobara
Copy link

The RFC 11 mentions an addition of sub_linker .

Note that a new API is also provided, sub_linker(). This method allows creating a "child" linker which inherits all of the previous values set by the parent but also allows defining new values in the returned value for instantiation.

It was not added yet, but it would be nice to have for my use case. I define a lot of host functions in the Linker, but then for each Store add a different module as an import. This immediately "poisons" the Linker with a particular Store and I need to re-add all the host functions again to a new Linker for other Stores.

Maybe, just having Clone on the Linker would be enough here.

@alexcrichton
Copy link
Member

Oh wow I completely forgot that Clone was a possibility here! I added that in #2993 because it seems pretty reasonable to me. The runtime of that will be slower than the sub_linker idea because things need cloning, but is that ok for your use case?

@bkolobara
Copy link
Author

I always assumed that the most expensive part of adding host functions was the trampoline creation, and this would be faster with cloning, instead of recreating Linkers?

The previous api Config::wrap_host_func was a perfect fit for my use case, but I think that Clone should also be fine.

Thanks for the super fast response!

@alexcrichton
Copy link
Member

Whether or not it's fast sort of depends on your use case and which part you're stressing. Want to try out the Clone impl though and see if it works for you?

@bkolobara
Copy link
Author

I ran some benchmarks with the Clone implementation. It takes around +35% more time per request in our current system, compared to an implementation that doesn't clone the Linker.

This is still significantly better than what we do right now, re-creating the Linker from scratch (15x slower), because we need to use different Stores with each.

The only issues is that it keeps getting worse if I artificially increase the number of host functions (with 200 the throughput decreases 50%). I expect the number of host functions to further grow in our system.

I would still love to see a sub_linker() API in the future, that doesn't decrease performance with more host functions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants