クイックソートで気になりませんか？

特に「標準」（非HPC）アプリケーションを作成する場合、どのソートアルゴリズムを選択するか、またはクイックソート（ほとんどのライブラリが単にソートと呼ぶもの）で解決するかを検討しますか？特定の状況ではある程度利益を生む可能性がありますが、一方で適切な最適化には、問題を分析してベンチマークを作成するためにある程度の時間が必要です。

一般的に、よりエキゾチックな何かをする特別な必要がない限り、デフォルトのメソッドを使用すると、すべてのものが読みやすく、理解しやすくなります。

複雑さを増す時期であるパフォーマンスの問題があると経験した場合（または場合によっては強く疑う場合）。

一方、使用するオブジェクトの種類に対応する組み込みのソートがないほど十分に低い言語を使用している場合は、ソートする必要があるオブジェクトのすべてをカバーする1つまたは2つを選択して、それらを実装してみてください。

提供しないライブラリルーチンを呼び出すのは、呼び出しを行わない非常に十分な理由がない限りです（その理由を文書化する必要があります）。

これは、並べ替えアルゴリズムを完全に正しくすることが難しいためです。非常に大きなデータセットを含むJavaクイックソートにバグがあり、Sunによって識別、修正、および顧客に提供されたため、その必要はありませんでした。

また、Java 7のデフォルトのソートは、新しい、より良いソートにアップグレードされました。また、無料です。

デフォルトのソートでは十分でない場合がある場合を除き、そのまま使用します。

ある会議で、私はこれについて素晴らしい話を聞きました。

マイクロソフトでは、誰かがVBアプリ（c。VB 3）を書いていて、大量の値を持っているので、コンボボックスに順番に表示してほしいと言ってたくさんの人にメールしました。

誰もが古いコンピュータサイエンスの教科書を求めて急降下し、非常に効率的なルーチンを探し、それらをVisual Basicに移植して郵送しました。1人の男が「コンボボックスの値はいくつですか？」

「約50」という返事が来ました。

「sortedプロパティをTRUEに設定するだけ」。

99.9999％のインスタンスでは、ライブラリ、コントロール、またはSQL selectを使用して並べ替えを行うのが最適です。ライブラリルーチンと作成したもののパフォーマンスの違いは無視でき、労力とメンテナンスのオーバーヘッドが結果を大幅に上回ります。

これは時期尚早の最適化に関する古典的な引用を引き出す時です。ほとんどの場合、それは本当に重要ではありません。最近のCPUの速度では、ほとんどのデータセットをバブルソートしても、それほど気付かない可能性があります。ただし、非常に大きなデータセットを並べ替えているときに、並べ替えのパフォーマンスが問題になり始めたら、他のオプションを確認する必要があります。

それは明らかにビットとタイムスライスには関係ありませんが。マージソートは、クイックソートよりも記述と理解が簡単であると思います。したがって、独自の並べ替えアルゴリズムを作成する場合は、それを使用します。

少なくとも、sort適切に作成されたライブラリでは、組み込みは単なるQuicksortではなくIntrosortとして実装されることを期待しています。違いがほとんど問題になることはめったにありませんが、Introsortは、より一般的なケースへの影響を最小限に抑えて、Quicksortの悪い最悪の場合のパフォーマンスを排除します。

しかし、あなたの質問に答えるには：はい-それはあなたが通常始めるべきことです、そしてそれが問題であることを示すプロファイラー結果があるまでは、それはそこに留まるべきです。