回答:
これは実際には、いくつかの方法論的で実用的な答えがある深い問題です。手元のアルゴリズムについて何か知りたいと思います。特定の入力で特定のマシンでどのアルゴリズムがより適切に機能するかを知りたい場合は、実行時間を測定してください。特定のアルゴリズムのコンパイラの品質を比較する場合は、先に進み、ランタイムを測定します。アルゴリズムについて何かを学ぶために、それをしないでください。
まず、ランタイムを使用するのが良い考えではない理由をいくつか説明します。
ランタイムはアルゴリズムを比較するための恐ろしい尺度であり、アルゴリズムランタイムを調査するための一般的で抽象的な方法が必要であることをこれらが納得することを願っています。
質問の2番目の部分に進みます。比較または同様の基本演算を使用するのはなぜですか？
分析の扱いやすさ
正式な分析を行うには、それを実行できる必要があります。個々のステートメントを数えることは非常に技術的であり、時には難しいこともあります。それにもかかわらず、一部の人々はそれを行います（例：Knuth）。一部のステートメント（ランタイムを支配するステートメント）のみをカウントする方が簡単です。同じ理由で、最悪の場合のランタイムを「のみ」調査します（上限）。
優位
選択した操作がランタイムを支配します。それは、それが最もランタイムに貢献することを意味するものではありません-ワードサイズの整数をソートするときのクイックソートなどでは、比較は明らかに貢献しません。しかし、それらは最も頻繁に実行されるため、それらをカウントすることにより、アルゴリズムの最も実行された部分が実行される頻度をカウントします。したがって、漸近ランタイムは、支配的な基本操作の数に比例します。これが、比較のみをカウントする場合でも、ランダウ表記と「ランタイム」という言葉を使用することに慣れている理由です。
複数の操作をカウントすると便利な場合があることに注意してください。たとえば、一部のQuicksortバリアントは、他のものよりも多くの比較を行いますが、スワップは少なくなります（平均）。
価値のあることについては、すべての理論を実行した後、理論が行う予測が適切であることを確認するためにランタイムを再検討することができます。そうでない場合、理論は（実際には）有用ではなく、拡張する必要があります。メモリ階層は、重要ですが、基本的な分析では欠落していることを最初に認識することの1つです。
これは、アルゴリズムを実行する合計時間が、他の要因とともに実行されるハードウェアに依存するためです。一方がPentium 4で実行され、もう一方がCore i7で実行されている場合、2つのアルゴリズムを比較することは信頼できません。これだけでなく、同じコンピューターで両方を実行したとしましょう。どちらも同じプロセッサ時間を持っているとはどういうことですか？あるアルゴリズムのプロセスよりも他のプロセスの優先度が高い場合はどうなりますか？
これを乗り越えるために、この全体の時間から切り離して完了し、代わりにアルゴリズムのスケーリングに基づいて比較します。あなたは、研究論文でO（1）またはO（n ^ 2）などの表記に気づいたかもしれません。興味のある人はBig O表記を参照してください。
他の回答では、基本操作の数に関してランタイムを分析する理由を説明しているため、比較が多くの（すべてではない）ソートアルゴリズムの正しいメトリックである理由をいくつか説明します。