プログラムが正しく動くならどのようなコードを書いてもいい、ということはない。
普段の研修課題では自分が書いたコードを先輩社員にレビューしてもらうため、可読性を意識してコードを書くようにしている。
そのため、「わかりにくいが少し速いコード」と「わかりやすいが少し遅いコード」であれば後者が望ましい。
プログラミングコンテストは普段の研修とは趣旨が違い、至高のコードは「実行時間が短いコード」である。
至高のコードを求め、３日間のプログラミングコンテストで自分が特に意識したことは「アルゴリズムを工夫して計算量を抑える」、「速くするための小技をたくさん使う」、「ファイル入出力の処理を工夫する」である。
１日目。
問題が渡され、まずは実行時間を気にせず正解となるコードを書くことを目標にしたが、これがなかなか難しい。
誰もが最初に思いつくであろう、ファイルの内容を最初に全て読み込んで計算させるコードを書いてみたが、メモリーの使い過ぎでルール違反になってしまう。
ファイルを少しずつ読み込んで必要なデータを保管して不要なデータを破棄する等、なんらかの工夫が必要である。
ファイル入出力のより良い方法を調査をしたり、アルゴリズムを考えたりしているうちに１日目が終わった。
２日目。
正解となるコードが書けた。
プログラムの実行時間は１０秒くらいで、すごく遅い。
コードを整理して２日目の記録は最終的に８秒くらいになった。
帰りの電車の中で、ある処理の計算量を大幅に抑えられるアルゴリズムを思いついた。
３日目。
早速、計算量の少ないコードに書き換え、「速くするための小技」をふんだんに盛り込んだ。
プログラムを実行してみたが、期待していたほどタイムは縮まらなかった。
実行時間の計測区間を細かく分けて計測してみると、全体の実行時間のほとんどがファイルを読み込む処理にかかっていることがわかった。
ファイル読み込み以外の処理が一瞬で終わるようになったとしても、全体のタイムにほとんど影響しないのである。
ファイル読み込み関連の処理をいじって最終的なタイムは３秒くらいになった。
実行時間を短くするためにアルゴリズムを考え、試行錯誤しながらコードを書き換える作業はとても楽しかった。
出来上がったコードを改めて眺めてみると、何をしているのか自分でもよくわからないコードができていた。
少しでも実行時間短くしようと思って「速くするための小技」を盛り込んだのが原因である。
プログラミングコンテストを通じて、「実行時間を遅くしている主要な要因を探し出し、その部分を改善することが大事」ということを学んだ。
