golang.tokyo#3 に参加してきました

ブログ参加枠がまだ空いていたので滑り込みで参加させていただきました。
ブログ参加枠というと相応のPVがないと参加できないのかと思いましたが、ぜんぜん心配する必要はないとのことでした。
golang.tokyo 参加者のブログがあまり観測できていないみたいです。
今回抽選に漏れてしまった人は倍率の低いブログ参加枠おすすめです。

ぼくもイベントの開催側にいたことありますが、いろんなブログでイベントのことが触れられていると嬉しいです。ブログやっている人はぜひ。


今回のメインテーマはパフォーマンスでした。登壇者の方々貴重なお話をありがとうございました。

  • Accelerating real applications in Go - 久保達彦(id: cubicdaiya) / 株式会社メルカリ
  • DevOps Performance Optimizations - Carlo Alberto Ferraris / 楽天株式会社 [twitter]
  • Streamの扱い方 - 辻 純平 / AWA株式会社
  • git-schemlexとddl-makerを使ったDB migrationの紹介 - Ryosuke Yabuki / 面白法人カヤック [twitter]
  • database/sqlとコネクション - 高橋 明 / 株式会社スプラウト [twitter]

発表資料はイベントページにあります。こちら

要約は同じくブログ参加枠で参加された nomotch さんの記事がおすすめです。なんども読み返しながら記事を書かせていただきました。ありがとうございます。


テーマがパフォーマンスということでコーディング部分ではメモリアロケーションやクライアントのコネクションの最適化の話題が多かったです。そんな中でメインセッションの久保さんとCarlo さんのGo言語のコーディングの話を超えて、インフラであったり開発スタイルの話は大変参考になりました。"YOU COST MORE THAN THE SERVERS" 大事ですよね。

ちょっと話は逸れるのですが、久保さんの発表で紹介されていた。github.com/kazeburo/chocon を読みました。ぼくも proxy サーバーを書こうと思っていたので大変参考になりました。github.com/kazeburo/chocon でも io.Copy が使われています。

io.Copy は内部的には io.copyBuffer(dst io.Writer, src io.Reader, buf []byte) (written int64, err error) が使われています。src が WriteTo メソッドを持っているか dst が ReaderFrom メソッドを持っていた場合はそちらを優先的に使います。bytes.Buffer はどちらも持っていてとても高速です。

確か、http.ResponseWriter は ReadFrom メソッドを持ってないと思いますし、http.Response.Body は WriteTo メソッドを持っていないと思います。このような場合は buf []byte を作って使い回した方が速いのではないかと思います。今度計測してみます。

http.ResponseWriterio.ReadFrom インターフェース対応してますね。失礼しました。


懇親会

人気のないハイボールと野菜たち

会場提供のサイバーエージェントさんからお酒とおつまみをいただきました。ハイボールが人気なかったみたいだったので、たくさんいただいてしまいました。

本当にありがとうございました。

じゃんけん大会

じゃんけん大会の景品のTシャツ

メルカリアッテのソウゾウさんからTシャツのプレゼントがありました。応募多数によりじゃんけんで決めることに。ぼくも欲しかったー。

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.