プログラムの実行時間を99％短縮した「たった1行のコード」とは？

プログラムの実行速度やウェブサイトの表示速度は、たった数秒の改善でも多くのエンジニアたちの苦心を必要としますが、時として拍子抜けするほどにあっけなく、かつ劇的な改善がなされる場合もあります。画像共有サービスのPinterestが自社のブログで「たった1行の変更でコードの実行時間を99％短縮した」事例を紹介しています。 How a one line change decreased our build times by 99% | by Pinterest Engineering | Pinterest Engineering Blog | Oct, 2020 | Medium https://medium.com/pinterest-engineering/how-a-one-line-change-decreased-our-build-times-by-99-b98453265370

[crosscrow]

“decreased our build times by 99%” を「プログラムの実行時間を99%短縮した」と訳すセンスのなさ。

[hase0510]

GIGAZINE、翻訳がいまいちだったりしがちなんだけど、日本で知られていない面白ネタを見つけてくるスキルはすごいので、感謝しつつ原文を見に行くのが最適ムーブかもしれない。

[burabura117]

exit(0) かと…

[andalusia]

プログラミングの世界では、O(n)の処理をO(1)に書き換えたら99%高速化するなんて日常茶飯事のことと思うけど。

[kako-jun]

Jenkinsfileですね。Java由来のGroovyという言語なので、プログラムという表現は正しいです。デプロイ時のcloneはターゲットブランチのみに限定することで無駄を省けというTIPS。デプロイするたびにお得を味わえます

[fai_fx]

現場猫(=^・^=)「速くなったから、ヨシっ！」

[Yutorigen]

Pinterest自体がPinterestユーザー以外の時間を削ぎまくってるんですが…

[Amigomr]

2500以上のブランチ....... 「改善前はリポジトリに存在する2500以上のブランチをすべてフェッチしてからmasterブランチをクローンする」

[Dragoonriders]

舐めたら遅くなる。舐めなかったら速くなったという割と当たり前の話。処理量に関わる設定パラメータやリファレンスをよく読もうという学び（舐める=全件チェックするくらいの意味）

[ad2217]

セキュリティ関連で無駄な時間を食っていることが多いので、そこを削ると大幅にスピードアップすることが多いと思う現場猫。

[deep_one]

プログラムじゃなくプログラムの発行だった。（いや、それもプログラムがやってるんだが。）

[yuji1626]

git

[alt-native]

“decreased our build times by 99%” ビルドと実行時間は違うやろ

[a96neko]

あとで読もう

[kaz_hiramatsu]

ブランチ多過ぎんか

[rryu]

gitはこういうことをする時はこのオプションを付けないと死ぬ系の罠がぼちぼちある感じがする。

[iekusup]

ほー。

[machupicchubeta]

"改善前はリポジトリに存在する2500以上のブランチをすべてフェッチしてからmasterブランチをクローンするという、効率の悪い状態でした。"

[leokun0210]

exitを1行目に書く

[adsty]

処理対象のブランチの範囲等を指定できるオプションを追加した。

[urandom]

Gigazineのテック系ネタはだいたいHackerNewsかRedditのトップに出てきたやつだよ（これもおそらく昨日のHNから https://news.ycombinator.com/item?id=24877034 ）

[NOV1975]

「とのこと」「とのこと」「とのこと」これがgigazineクオリティ

[bigchu]

改善後のコードで追加されたのは、処理対象のブランチの範囲などを指定できる「refspec」オプション

[bopperjp]

読めば理解できることにいちいちツッコミをいれるような媒体じゃないから。それよりも、「refspec」について知っていたかどうかの方がよっぽど重要。

[kazuph1986]

クローンに40分掛かるPinterestのgitリポジトリ。

[a20130517]

未だに作業の成果としてステップ数で評価してるアホもいるのに

[daishi_n]

そういや、カトラーがNT3.1を開発していたときは学生バイトに夜間ビルド、ビルド後テストさせて出勤時間の前にビルド成功・失敗の旗をMS社屋に掲げてたっけ。今はデプロイ回数に比例してビルド回数も増えてるからなー

[korosuke613]

頭抱えるブランチの多さ　> “リポジトリに存在する2500以上のブランチ”

[Kesin]

これは割と本当にある話で、gitのrefspecについて理解している人はそう多くないと思う。大規模リポジトリのCIでgit clone時間に悩んでいる人は、depthやshallowと一緒に調べてみることをオススメします

[raimon49]

「いや役割を終えたリモートブランチは都度消しとけよ」とツッコミたくなってしまうが、運用上の理由があって2,500以上も存在したのかな。

[mn_kun]

タイトルbreak;

[kekera]

実行時間ではなくビルド時間じゃん

[natu3kan]

調べたら、不必要に広い範囲を読み込んでて無駄に処理が長くなるとかは普通にあるが、忙しくて、仕様というか文化として温存されるケースはある。コードを変えると安全確認のテスト項目が数千、数万とかありうるし。

[t0ng]

ビルドが実行時間になってて草

[napsucks]

動作速度が遅いという相談を受けて調査したら、GDI再描画を高頻度のループ処理の中にぶっこんでるというタコプログラムに遭遇したことがある。

[atsushifx]

元記事 https://medium.com/pinterest-engineering/how-a-one-line-change-decreased-our-build-times-by-99-b98453265370 。checkout用のGroovyスクリプトにrefspecを加えた。スクリプトにはdepth と shallow オプションもつけてあったが、十分ではなかった

[eiki_okuma]

return;

[kikai-taro]

この記事の目的は、読者におけるコード屋の含有量を推定することかも。

[circled]

SQLとか処理時間に1秒以上かかるやつは書き方がおかしい場合が多いので見直した方が良い(インデックスがあるのに使われてなかったりみたいなこともある)。500ms以上の処理は基本全部見直しておけば、後のスケールが楽。

[Cujo]

/* */