nilが欲しいからと言ってむやみにポインタを使うとひどい目にあう話 - moriyoshiの日記
スマートフォンアプリ側の実装担当として少し関わっているあるβ版のサービスで、奇妙だが比較的クリティカルな問題が発生していた。 それもメッセージが関係ない人間に届くというものであった。 なんとなくその問題を担当することになったが、常に状況が再現するわけではなく、他の仕事もあったので、問題への見当を付けられないまましばらく過ごしてしまった。 そのメッセージを送信する部分はサーバサイドのコードで、Goで書かれていた。 そのコードのエッセンスを抽出すると、以下のようになる。 package main import ( "fmt" "sync" ) type User struct { Id int Name string } type Mail struct { Title string UserId *int } func sendMail(mail Mail, wg *sync.WaitGro
なぜ私達は Python から Go に移行したのか - Frasco
新しい言語に移行するのは常に大きな決断です。その言語をよく知る人がチームメンバーに1人しかいない時などは特にそうです。今年の初め、我々は Stream の主要言語を Python から Go に切り替えました。この記事では、なぜ私達が Python から Go に移行しようと決断したのか、その理由を説明します。 Go を使う理由 理由1 - パフォーマンス Go は速いです! Go は極端に速い。そのパフォーマンスは Java もしくは C++ に匹敵します。私達のユースケースでは、Go は Python より30倍速いです。Go と Java を比較したベンチマークはこちらです。 理由2 - 言語パフォーマンスの問題 多くのアプリケーションにとって、プログラミング言語は、単にアプリとデータベースを繋ぐものにすぎません。言語そのもののパフォーマンスは通常あまり重要ではありません。 しかしな
Go のバイナリには -ldflags '-w -s' でコンパイルしてもたくさんパスが埋め込まれていた - Qiita
とコンパイルすることで、 DWARF とシンボルテーブルの情報をバイナリに残さずコンパイルできる。 しかし、自分は気になったので strings コマンドを生成後のバイナリにかけてみた。 するとバイナリには というような行が、まだたくさん残っていた。 どうやら DWARF やシンボルテーブルの情報を削除しても、コンパイルの際のパスなどの情報は残ってしまうようだ。 消してみると 10% くらい節約できた そこで、全て浅いディレクトリでコンパイルしなおしたところ、約 5MB のバイナリが約 4.5MB ほどまで節約できた。 ソースコードを細分化していればしているほど、モジュールを使っていれば使っているほど、含むパスは多くなるので、これらにより節約できるサイズは大きくなる。 Go の単一バイナリを Docker コンテナにするような状況では、 10% の節約は心理的に大きい。 (嬉しい) 使い所
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
