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

Better v-table storage #70

Open
p-avital opened this issue May 3, 2024 · 1 comment
Open

Better v-table storage #70

p-avital opened this issue May 3, 2024 · 1 comment

Comments

@p-avital
Copy link
Collaborator

p-avital commented May 3, 2024

1.78 has introduced a regression that prevents stabby from implementing trait-object construction as efficiently as before.

This issue tracks progress in mitigating this problem into core::marker::Freeze is stabilized.

@p-avital p-avital changed the title Better v-table sorting Better v-table storage May 3, 2024
@xuchaoqian
Copy link

xuchaoqian commented May 4, 2024

Benchmark feedback:

1. I constructed a use case as follows:

host ---> stabby plugin ---> host
The host asynchronously calls stabby plugin's API, which asynchronously callbacks the host.
vs.
host ---> host ---> host
The host asynchronously calls its own API, which asynchronously callbacks the host.

The goal is to compare stabby's async approach versus the native async approach in both the nightly and stable channels.

2. Here is the result:

image

3. Conclusion:

1) Stabby in the nightly channel is 20%+ faster than stabby in the stable channel.
2) Stabby's future implementation is 2-3 times slower than the native async implementation.

If you're interested, you can check the code here: stabby-plugin-demo

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