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

Remove Revolt\launch #6

Merged
merged 1 commit into from
Oct 17, 2021
Merged

Remove Revolt\launch #6

merged 1 commit into from
Oct 17, 2021

Conversation

kelunik
Copy link
Member

@kelunik kelunik commented Oct 17, 2021

As all event callbacks and queue automatically create a new fiber upon suspension, there's no need for a separate function anymore. EventLoop::queue can be used as direct replacement without the need to even create a new fiber if there's no suspension happening.

This is building on top of #3.

As all event callbacks and queue automatically create a new fiber upon suspension, there's no need for a separate function anymore. EventLoop::queue can be used as direct replacement without the need to even create a new fiber if there's no suspension happening.
Copy link
Contributor

@WyriHaximus WyriHaximus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Love the clean up, but somehow missed that we run each futureTick/timer callable in a fiber. Not sure what the performance implications of that are but will get back to that later.

@trowski
Copy link
Member

trowski commented Oct 17, 2021

Not sure what the performance implications of that are but will get back to that later.

For 100,000 watcher invocations the overhead was about half a second on my machine, going from about 2.5 seconds to 3 seconds. I think the usability win is well worth the performance penalty. Obviously any real-world application will be limited by what the callbacks are doing more than the fiber-swtich overhead.

@trowski trowski merged commit 903edcb into main Oct 17, 2021
@trowski trowski deleted the remove-launch branch October 17, 2021 18:18
@WyriHaximus
Copy link
Contributor

Not sure what the performance implications of that are but will get back to that later.

For 100,000 watcher invocations the overhead was about half a second on my machine, going from about 2.5 seconds to 3 seconds. I think the usability win is well worth the performance penalty. Obviously any real-world application will be limited by what the callbacks are doing more than the fiber-swtich overhead.

Hence why I want to try it out before raising it as an issue 😄 .

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

Successfully merging this pull request may close these issues.

3 participants