Is Echo is more efficient than Gin? #2143
-
|
According to Echo README, Echo is faster and more efficient than Gin as of 2020. However, Accord got Gin homepage, Gin is faster and more efficient as of 2022. |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 9 replies
-
|
You should take this with grain of salt. Every library claims that it is the best. Looking from Gin repo its seems that their benchmarks are also quite old (from May 2020 https://github.com/gin-gonic/gin/blob/master/BENCHMARKS.md) NB: these benchmarks hardly ever include middlewares and does not represent real world use cases. I have run same tests with latest Echo and Gin and result is https://github.com/aldas/web-framework-benchmark/actions/runs/2017913749 or from my own machine: The most notable difference between Gin and Echo is how handler functions look like. func mainEcho() {
e := echo.New()
e.GET("/test", func(c echo.Context) error {
return c.String(http.StatusOK, "OK")
})
}
func mainGin() {
g := gin.New()
g.GET("/test", func(c *gin.Context) {
c.String(http.StatusOK, "OK")
})
} |
Beta Was this translation helpful? Give feedback.
-
|
Github action gives these numbers https://github.com/aldas/web-framework-benchmark/runs/5632355823?check_suite_focus=true |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for actually running the benchmark. It is quite helpful. |
Beta Was this translation helpful? Give feedback.
-
|
Unless you are serving thousands of request per second I believe there is no meaningful difference in top 10 Go web frameworks. I suggest to base your decision on features that web framework provides, documentation and how active the community is. Going from Echo to Gin and back is quite simple if you structure you application in layers. You handlers are your transport layer and your business logic should go into business layer - separate those and you can switch between frameworks in little effort in the future. Make your handlers extract data from request and pass it to business layer (maybe services) etc |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the advice. |
Beta Was this translation helpful? Give feedback.
-
|
If you are on these scales you probably have engineering department that can build proof-of-concepts and measure performance for your use-case. These benchmarks that you see completely ignore middlewares which may sway the balance between frameworks - middlewares you choose by your requirements. Performance number that you see are mostly routing related and there are not much that can be improved (we are dealing nanosecond scales for these parts). At some point you need to start drop/remove features to get performance. It is cheaper to spin up new instance that invest potentially hundreds or thousands of manhours to squeeze couple of microseconds here and there. I would say if benchmark performance difference is below 10% - there is no difference. Try not to simplify performance just to web framework level. Measure bottlenecks first at your whole application/system level. Take framework that fills your requirements and feels natural/good to develop with. Most of the time - focusing on "time to market" is better than thousandths of a second here and there. p.s. Gin is always a good choice if Echo does not feel right |
Beta Was this translation helpful? Give feedback.
-
|
That's great to know when I need to scale up. Thank you very much for detailed explanations. |
Beta Was this translation helpful? Give feedback.
-
|
@aldas thank you for the clear explanation. Few weeks ago i am wondering if gin would be better choice for my next projects since people said it is faster. After reading your explanation, i think i will stick with echo since echo is i think better structured and has neat documentation. The only downside is majority of example in SOF is using gin or native (no framework) |
Beta Was this translation helpful? Give feedback.
-
|
Dear Faridalim, what is SOF ? thank you |
Beta Was this translation helpful? Give feedback.
-
|
SOF = Stockoverflow |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for clearly addressing the performance matter. I had the same question. But apart from performance, for me, project structure is very important factor in the choice of a good go library. Just from the looks of it, echo seems to me to be better aligned with golang conventions/guidelines. One step deeper in gin, I see that I used echo for the first time ~5 years ago. Early on, one day I noticed that beego has way more stars on github compared to echo. (gin had almost equal or maybe even less stars than echo at that time). I put some serious time to see how beego works, so I can make a switch if it's necessary. But all I saw then was redundant and bloat code. Today I was put off by gin for the same reasons. They're in my mind examples of 'golang done wrong'. The logic in a large web app can get quite messy and intertwined. Having to go through 20+ similarly named framework methods that do ~similar things will just add to the headache. I extended |
Beta Was this translation helpful? Give feedback.
-
|
Probably useful for the reader, what is the differences between Echo's context uses interface and Gin uses struct and the impact of using either one? |
Beta Was this translation helpful? Give feedback.
-
|
I can not really say why Echo has interface. Probably because in older versions Echo supported FastHTTP but I could be that Interface existed even before that (@vishr knows the best). If you think from design perspective interface would probably be first thing in your mind what Context should be. Interface can have different implementations etc. In reality I think creating your own context is not a thing with Echo. It is a lot of work and provides little value. I really can not think any practical use-case for it. I really do no think that mocking
This is simplified and modified example for calling Echo handlers by passing in struct and interface. package main
type InterfaceHandlerFunc func(c Context) error
type StructHandlerFunc func(c *defaultContext) error
type Context interface {
Set(counter int) error
}
type defaultContext struct {
counter int
}
func (dc *defaultContext) Set(counter int) error {
return nil
}
type server struct {
exampleStruct *defaultContext
exampleInterface Context
}
func newServer() *server {
return &server{
exampleStruct: &defaultContext{},
exampleInterface: &defaultContext{},
}
}
func (s *server) ServeStruct(counter int) {
var h StructHandlerFunc
h = func(c *defaultContext) error {
return c.Set(counter)
}
_ = h(s.exampleStruct)
}
func (s *server) ServeInterface(counter int) {
var h InterfaceHandlerFunc
h = func(c Context) error {
return c.Set(counter)
}
_ = h(s.exampleInterface)
}
func main() {
s := newServer()
for i := 0; i < 10; i++ {
//s.ServeInterface(i)
s.ServeStruct(i)
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the excellent explanations, I got a new question related to framework efficiency. |
Beta Was this translation helpful? Give feedback.
-
|
I think Echo is more efficient for development with clearer documentation than Gin |
Beta Was this translation helpful? Give feedback.
You should take this with grain of salt. Every library claims that it is the best. Looking from Gin repo its seems that their benchmarks are also quite old (from May 2020 https://github.com/gin-gonic/gin/blob/master/BENCHMARKS.md)
NB: these benchmarks hardly ever include middlewares and does not represent real world use cases.
I have run same tests with latest Echo and Gin and result is https://github.com/aldas/web-framework-benchmark/actions/runs/2017913749
or from my own machine: