search

gin-gonic / gin

Gin is a HTTP web framework written in Go (Golang). It features a Martini-like API with much better performance -- up to 40 times faster. If you need smashing performance, get yourself some Gin.
https://gin-gonic.com/
MIT License
76.96k stars 7.92k forks source link

Huge dependency #1847

Open john8329 opened 5 years ago

john8329 commented 5 years ago

Using go 1.12, latest version of gin to date, I analysed my executable and I see that 11MB are occupied by the dependency github.com/ugorji/go/codec. Does really gin need all of this package?

tqcenglish commented 5 years ago

some result through goweight

sairoutine commented 5 years ago

github.com/ugorji/go/codec is used to output msgpack. It is huge because codec supports not only msgpack but also cbor, json.

It should be better we thinking to use other msgpack libraries instead of it.

Hades32 commented 5 years ago

Just realized just the same thing. That's ridiculously large for a hello world http server.

I would argue that MsgPack support shouldn't be part of core Gin anyway. It's not a super common format like Json. Some goes probably for github.com/golang/protobuf ~2MB...

IMHO it would make more sense to have a gin-msgpack and gin-protobuf dependency. Looking at it this would probably require making default content-type bindings and renderers plugable, but this seems to be a good idea anyway...

ravener commented 5 years ago

i agree, those dependencies should be someway optional or as another plugin package, in most cases i don't think a user would need those dependencies.

john8329 commented 5 years ago

Good frameworks are built up in modules. As we don't expect gin to have other useful stuff like jwt, it shouldn't include by default a relatively more obscure encoding for no reason, in my own opinion.

dmarkham commented 5 years ago

So go in general is just a little over the top in executable size. If we were all prioritizing saving 2MB we would be writing in rust or c.

I don't really like the build tags option either. Last thing I want to think about is all the build tags we end up adding add then having to support in the future.

Now that binding has been refactored into a nice interface. Seems like we should be able to get all none builtin encoding's moved out into something that registers itself with gin on a per app basis maybe similar to how sql drivers do it. We can do better!

sapk commented 5 years ago

@dmarkham the build flag is mainly to have non-breaking optimization but a system like sql drivers should be better and should not be that difficult to setup. The most difficult point would be the current select of content-type in the binding module. The rest could already be 'pluggable' but that would break reverse compat with older version and would need a v2 versioning.

dmarkham commented 5 years ago

@sapk technically I don't think msgpack / protobuff have been in a released yet. They are being proposed to be included in v1.4.0 and that is not out yet. Maybe they should be the first to use a new ''pluggable" version, vs the first to to start a trend on being excluding via tags?

With that being said, I don't feel super strongly about it, and I guess I would been better if i thought about it back when #1479 was getting talked about.

guonaihong commented 5 years ago

If you remove github.com/ugorji/go/codec, it will automatically build faster for me.

thinkerou commented 5 years ago

About the issue, I may remove binding/msgpack and binding/protobuf, etc, and render/msgpack and render/protobuf, etc. And then we may have two method to solve the change:

  1. add gin-gonic/gin-binding and gin-gonic/gin-render, it will like #1856
  2. not add gin-gonic/gin-binding and gin-gonic/gin-render, user realizes Binding interface and Render interface.
thinkerou commented 5 years ago

And gin.Context not use render.MsgPack and binding.MsgPack directly.