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

runtime: improve performance of runtime to match that of Evio #22714

Closed
rjammala opened this issue Nov 14, 2017 · 6 comments

Comments

Projects
None yet
6 participants
@rjammala
Copy link

commented Nov 14, 2017

@crawshaw mentioned in Hacker news that the performance of Go can be improved to match that of Evio: https://github.com/tidwall/evio

Filing this issue for tracking purposes. Please close if this is not appropriate.

@ianlancetaylor ianlancetaylor changed the title runtime performance: Improve performance of runtime to match that of Evio runtime: improve performance of runtime to match that of Evio Nov 14, 2017

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Nov 14, 2017

I don't understand what action this issue will lead to. We are always trying to improve the performance of the runtime.

@crawshaw I couldn't find the Hacker News comment. Did you have a specific suggestion?

@rjammala

This comment has been minimized.

Copy link
Author

commented Nov 14, 2017

@ianlancetaylor : Here is the full comment.

crawshaw 10 days ago [-]

One of my favorite things about Go is that it cuts through the "threads vs. events" debate by offering thread-style programming with event-style scaling using what you might call green threads (compiler assisted cooperative multitasking that has the programming semantics of preemptive multitasking).
That is, I can write simple blocking code, and my server still scales.
Using event loop programming in Go would take away one of my favorite things about the language, so I won't be using this. However I do appreciate the work, as it makes an excellent bug report against the Go runtime. It gives us a standard to hold the standard library's net package to.

@thanm

This comment has been minimized.

Copy link
Member

commented Nov 14, 2017

Is this the full thread-- https://news.ycombinator.com/item?id=15624432 ?

@bradfitz

This comment has been minimized.

Copy link
Member

commented Nov 14, 2017

As Ian said, we're always working to improve performance. If there's nothing concretely actionable here, let's close this bug.

@rjammala

This comment has been minimized.

Copy link
Author

commented Nov 14, 2017

@thanm : Yes, that is the thread. @crawshaw : I am closing this bug. Please reopen if you think it is appropriate.

@rjammala rjammala closed this Nov 14, 2017

@crawshaw

This comment has been minimized.

Copy link
Contributor

commented Nov 14, 2017

FWIW, I spent about an hour after writing that trying to extract a useful benchmark from evio, but couldn't get anything small and stable that was worth submitting to the net package. I don't think this needs an issue, just someone to sit down and try to write a piece of code that we know can be faster by X%.

@golang golang locked and limited conversation to collaborators Nov 14, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.