Timing Our Code

わかりました｡ では､ もう少し具体的な例を見てみましょう｡ 同じ問題に対する2つの解決策を比較してみましょう｡ わかりました｡ そこで､ 私たちの問題です｡ 1からある数までのすべての数の合計を計算する関数を書きたいとします｡ N だから､ 3を入れると､ 1＋2＋3､ つまり6になるはずで､ 最も一般的というか､ 簡単に思いつく｡ 解決策 これは､ 基本的にトータル変数アキュムレータを作り､ すべての数字をループして､ 1から始まってNまで一度に足し算していくというものです｡ ということで､ ここではそのようにしました｡ forループがあります｡ Total変数は0から始まり､ 最後にtotalを返します｡ ループは1から始まり､ トータルプラスイコールで毎回nまで上がります｡ 実は､ 私にもあるんです｡ ここにスニペットとして開いています｡ スニペットに馴染みのない方のために説明すると､ 基本的には､ コンソールにコードをコピー＆ペーストして､ それを紛失して再実行する必要がないようにするための方法です｡ Chromeの場合､ SourcesタブでSnippetsタブをクリックすると､ 新しいスニペットを作成することができるんだ｡ このコースでは､ コードを保存して実行する簡単な方法として､ これらを頻繁に使用するつもりです｡ そして､ どのように機能するかを示すために､ ここに同じadd up to functionを示しますが､ 6を足した結果の下にプリントアウトしています｡ つまり､ 6＋5＋4＋3＋2＋1 で実行できるはずです｡ ここをクリックするか､ Macの場合はコマンド入力のショートカットが表示されます｡ PCでは正しいショートカットを言ってくれる｡ コントロールエンターだと思います｡ だから､ 今それをやると21になってしまうんです｡ 3人とかそこそこの人数でやったら6人になる｡ 100でやると5050になる｡ つまり､ それが機能することを実証するためのものです｡ 次に､ 2つ目の解決策です｡ この2つ以外にもありますが､ 私が言いたいことを説明するために､ この2つを使いました｡ こっちの方が断然直感的じゃないですか｡ ご覧の通り､ かなり短くなりました｡ 一本の線だから良いというわけではないのですが､ とても違いますね｡ ループは関係ない｡ 私たちがやっているのは､ どちらかというと数式的なものです｡ Nをとって､ N＋1÷2で掛け合わせるのです｡ この式がどのように導き出されたかは､ スライドをご覧いただくとして､ ここでは割愛させていただきます｡ 確認したい方は､ どうぞ｡ しかし､ それはこのビデオの焦点ではありません｡ ですから､ 実際の焦点であるコードの評価や比較から目をそらさないようにしたいのですが､ 実際にどのようにコードを書くかについては深く考えません｡ だから､ これを見せるだけで､ 効果があるんです｡ もうひとつ､ こちらにもスニペットがあります｡ 同じものを走らせることができる｡ もう一度6でやってみましょう｡ コマンドを入力して実行すると､ 21が得られます｡ ここで何が起こるかを説明すると､ 6に1/1を足したものに相当します｡ だから､ 効果があるんです｡ 結局は同じ答えが返ってくるんです｡ 繰り返しになりますが､ その仕組みは､ この辺にしておきましょう｡ B 分かりました｡ そこで､ 2つの解決策があることがわかりましたが､ どちらが良いのでしょうか？ そしてもちろん､ 最初に問うべきは､ より良いとは実際にどういうことなのか､ ということです｡ 秒単位､ ミリ秒単位で高速なコードを意味するのでしょうか？ 小さい数を足すときと大きい数を足すときで､ 一番速くなるコードということでしょうか？ 例えば､ ゼロから10億までの数字をすべて足し算するときにベンチマークを出したいとします｡ それは良いテストなのか､ それともメモリをどれだけ使っているかということなのか｡ その関数が呼ばれるたびに作成される変数の数､ 保存されるデータの数でしょうか｡ あるいは､ 読みやすさ､ 読みやすさのようなものはどうでしょうか｡ それがどれほど重要なことか｡ その方がいいのか？ それとも簡潔さ？ それはここにはない｡ でも､ 多くの人がそれを気にしているんです｡ 彼らは､ プログラミングで使用する文字の長さ､ 数を最小限にすることを好みます｡ 私個人のスタイルではありませんが､ 間違いなく有効です｡ これらはすべて正当な懸念であり､ 本当に状況次第なのです｡ しかし､ 最初の2つは､ 特に今はスピードに重点を置くというのが､ 多くの人の意見ではないでしょうか｡ メモリ使用量については､ また後ほどご紹介します｡ しかし､ この2つはしばしば可読性などよりも重要な場合があり､ 残念ながら可読性を犠牲にしてしまうことが多いのです｡ 良いコードを書くには､ メモリを大量に消費しない効率的なコードを書くことと､ 読みやすく､ ちんぷんかんぷんなコードにならないようにすることのバランスを取ることが大切です｡ そこで､ 基本的にコース全体を通して､ これらのすべてがどのように作用しているかをお話しします｡ 繰り返しになりますが､ 私たちはスピードの評価､ つまりコードの実行にどれくらい時間がかかるかを重視しています｡ スタートすることになりました｡ では､ どうすればいいのか｡ 一番簡単な方法は､ 内蔵のタイミング関数のようなものを使って､ 最初の足し算をするような方法です｡ ブラウザでは､ ドキュメントが作成されてから､ つまり基本的にはウィンドウを開いてから何ミリ秒経ったかだけを教えてくれるものです｡ そして､ add up toを呼び出す前にそれを変数に保存し､ それからadd up toを呼び出すのです｡ だから､ 10億なんです｡ 10億だと思います｡ だから､ 大きな数字で呼ぶことにしているんです｡ そして､ それが終わった後､ 今もう一度パフォーマンスをチェックします｡ おそらく､ 何ミリ秒かインクリメントされているはずです｡ つまり､ 2つの数字があったら､ 1回目か2回目にそれを引いて､ 1回目を引いて､ それを1000で割るんです｡ 最後の部分はやらなくていいので､ プリントアウトしています｡ これはうまくいくはずで､ 実際にここにスニペットがあります｡ 同じことです｡ だから､ さっきのやつに足して､ 10億で呼んで､ 経過時間をプリントアウトするんです｡ まずコンソールをクリアして､ 実行します｡ これでよしとしよう｡ 1. 2575. だから秒殺で､ もう一回やらせてください｡ そして､ 実際に目にするもの｡ 実行しなかったと思います｡ これでよしとしよう｡ 自分のパソコンでも変わるくらいバラバラなことでしょうか｡ 本当に何も変わっていないんです｡ コードを追加していない｡ ここは数字を変えていない｡ 全く同じコードなのに､ 違う出力が出るんです｡ 忘れないうちに､ 2つ目の解答に進みましょう｡ つまり､ まったく同じ数字なのです｡ 抜けやゼロがないか確認させてください｡ そう､ 同じであり､ 同じことをしているのです｡ 冒頭で今すぐパフォーマンスを取り出し､ 最後に今すぐパフォーマンスを取り出す｡ その様子をお見せした方がよさそうですね｡ 何分も開いていたので､ この時点でなんだか大きな数字になっているのがわかると思います｡ ページを更新すると､ 今したのですが｡ 今は2000ミリ秒で､ 2秒になります｡ そして今､ もう一度やったら6になった｡ 6秒 と差し引くと､ だいたい4秒の間です｡ とにかく､ ここでも同じことをやっているんです｡ さて､ これを実行すると､ かなり小さい数字が表示されますが､ 実際にはまだ､ ここで変化しているようには見えませんね？ 測定値､ 差は本当に､ 小さすぎて捉えられない｡ しかし､ 私が言いたいのは､ これと同じデータでは期間が大幅に短いということです｡ それでは､ 1． 2 4秒に対して､ 基本的に0秒｡ ということは､ このソリューションには良い兆しがあるように思います｡ より効率的になったようで､ 素晴らしいことだと思います｡ しかし､ このプロセスは､ このように手動で前後のタイミングを計り､ 他の関数と比較することが最も信頼できるものではありません｡ そして､ それは私たちにとって､ そう簡単に語れることではありません｡ 実際にどう書き留めるか？ これと比べて､ こっちは効率がいいというラベルをどうやって貼ればいいんだろう？ 速度の割合で判断しているのでしょうか？ 秒数かミリ秒を引くと､ 少しぼやけるのは､ Iなのか｡ ここで､ 終活の回顧録のタイトルに留保している時間の問題に行き着く｡ 時間の問題､ それはちょうどいい音で､ とても深い｡ 1つ目は､ マシンによって記録される時間が異なるため､ マシンの仕様や､ そのマシンで現在何が起こっているか､ どんなコードが動作しているかによって､ 得られる結果が異なるということです｡ だからといって､ 最初の解がいきなり2番目の解より速いという逆の結果が出るかというと､ 実はそうではない｡ しかし､ マージンが変化する可能性があるということです｡ 実測値は異なる可能性があり､ ほぼ間違いなく異なる時間帯になります｡ そして､ 見たとおり､ 同じ機械でも記録される時間が違う｡ ブラウザでまったく同じコード､ つまり最初の例を実行したところ､ 毎回ちょっとずつ違っていました｡ これは本当に問題ではないのですが､ やはり正確ではないので､ 当てにならないことがわかります｡ そして2つ目､ 3つ目は､ 高速なアルゴリズム､ つまり本当に速いスケールで起こっていることについては､ 速度計測では十分な精度が得られない可能性があるということです｡ 私たちは2つか3つか4つのアルゴリズムを持っていて､ それらはすべて超高速で､ 非常に素早く何かを行っています｡ しかし､ 測定可能な最小の時間間隔が十分でないために､ タイミング関数がそれを理解できないとしたら､ それは私たちの助けにはなりません｡ では､ どのようにすれば､ 実際にコードを見ながら､ どのコードが優れているかということを､ 時間をかけずに一般論として話すことができるのでしょうか｡ だから､ はっきりさせたいんです｡ コードのタイミングをとることが悪いと言っているのではありません｡ 私はいつもそうしていますが､ 私が言いたいのは､ 新しいファイルをセットアップして､ 実際にコードのタイミングを合わせるプロセスを必要としない別の方法があれば､ クールだろうなということです｡ もし､ 私たちのコードが1時間かかるとしたら？ 何か重厚感があり､ 4時間かかる別バージョンと比較しています｡ どちらが速いか､ テストをするのが面倒なんです｡ 私たちは､ 一般的な用語で､ コードが他のコードとどのように比較されるかを､ このようなことをすべて行うことなく､ 値を割り当てることができるようにしたいのです｡ そして､ そこで登場するのがビッグノートです｡ そして､ それは次に出てくるものです｡ クリフハンガー､ ごめんなさい｡