Go本体にContribute成功した話 と Gerritの話 - stanaka's blog
来月ぐらいにはGo 1.7がリリースされそうなのですが、CONTRIBUTORSに名前が載せられそう( https://github.com/golang/go/blob/release-branch.go1.7/CONTRIBUTORS#L915 )なので記念エントリです。 内容自体は、4月にあったGoCon 2016 Spring( http://gocon.connpass.com/event/27521/ )での発表済みです。 tl;dr 一部のディストリの最新版でlinux/386でビルドしたバイナリが起動すらできない、というバグがあった 問題はruntimeのアセンブラ部分だったけど、なんとかパッチ書けた パッチ提出→コードレビュー→やりとり→マージまで、3日程度とスムーズに進行できた https://go-review.googlesource.com/#/c/21190/
Goのバイナリサイズを削減する — そこはかとなく書くよん。 ドキュメント
あれ、 "-s"では変わってないですね…darwin環境ではでないのかななld周りのなにかだと思うのでそれはあとで追うとして、元々が26MBだったのが、5.2MBまで減りました。 圧縮に upx -9 を使った場合、かかった時間は15.70秒でそこそこ時間がかかりますね。3回ほど実行してだいたい同じぐらいでした。伸長時は0.10秒ほどでした。もちろんメモリなどにも依存しますので、この結果は鵜呑みには出来ませんが、あくまで目安として。 さらにいうと、 upx -1 で圧縮した場合は 0.78秒しかかかりません。それでいて、6.4MBと充分な圧縮効率となりました。この辺りはターゲットとする環境に合わせて決めればいいと思いますが、 -1 で十分な気もします。 まとめ¶ Goのバイナリが大きい問題は、ldflagsとUPXを使うことである程度解決できるのではないか、という話でした。 UPX知らなか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
