メモリ管理のO（log n）は遅いと考えられていますか？
たとえば、グローバル「ヒープ」からの単一スレッドの汎用メモリ割り当て/割り当て解除について話している。すべてのCプログラマーは、malloc（）/ free（）の形式で知っています。
私は、はるかに優れているが、ある程度は制限されているユースケースのアロケーターに関する論文の実際のタイトルを述べることはできませんが、同じ判断を何度か読んだと思います。たとえばに関するコミュニティの意見n =管理対象メモリのサイズに対してO（log n）を持つバランスツリーは、非常に遅いということです。このパターンはかなりまれなパターンだと思いますが、いくつかの高周波ループ構造について話していると問題がわかります。ただし、O(n)アルゴリズム（n =メモリセル内のオブジェクトのサイズ））で後で使用されるオブジェクトの時々の割り当てでは、影響はかなり小さいですそれでも、そのようなアロケータについての世論は、それらがあまりにも原始的であり、リアルタイム環境ではあまり使用できないということのようです。
人々の心の中のアルゴリズムの「理想的な」パフォーマンスは、そこにある最良のオプションが何であるかに依存しています。 O（n log N）時間でデータ構造に対して「検索」操作を実行できる場合、それで十分ですか？多分そうです。ただし、多くの構造体ではO（n）またはO（log n）でも検索できるため、人々はあなたのO（n log n）を「遅い」と呼びます。これは実際には遅いからではなく、ニーズを満たす高速のアルゴリズムがあるためです。
一般に、人々はO（log n）よりも高速に実行され、メモリ管理に対する期待に応えるアルゴリズムを見つけました。したがって、O（log n）アルゴリズムは、この速度の変化を相殺するための価値のある機能を提供しない限り、一般の人々によって「遅すぎる」とマークされます。この50HPスポーツカーのユニークな価値を示すことができない限り、スポーツカーがすべて250 + HPを備えている国では、50HPモーターを搭載した多くのスポーツカーを販売しません。多分それはより安いか、それは生分解性です。
ほとんどの開発者singこれらのメモリ管理アルゴリズムは、基盤となるAPIのコストについて考える必要はありません。彼らがconsiderのメモリ管理の漸近的な実行時パフォーマンスさえもしなければならない場合、それは彼らにとって遅すぎる。彼らはそれを拒否します。
これはすべて、実際のメモリ管理ライブラリは、単純なBig-Oh表記よりも微妙な方法でパフォーマンスをモデル化する必要があることを意味します。 Big-Ohは素晴らしいですが、彼らが興味を持っているようなパフォーマンスについては、それは十分ではありません。メモリマネージャーは、Big-Ohが単に無視する、実行速度を制御する実際の時定数に注意する必要があります。ランタイム分析には、ブランチの予測ミスやジッター、ランダムでない読み取り/書き込みなどが含まれており、パフォーマンスを数パーセント向上させています。
したがって、最終的に、O（log n）アルゴリズムと、64バイト未満のオブジェクトを割り当てるために3サイクル、大きなオブジェクトの場合は20から40サイクルを必要とする出血エッジ調整アルゴリズムのいずれかを選択した場合、選ぶ？
「遅い」はアプリケーションによって異なります。一部のリアルタイムアプリケーション（高速機械制御、DSPなど）の場合、制限のないレイテンシは遅すぎて、破局的な障害モードにつながる可能性もあります。これらのアプリケーションでは、O(1)コードは安全であると確認するのが簡単です。O(logN)は、Nが厳密に制限され、要件内にある場合にのみ安全です。また、max（N）の決定、検証、またはテストが困難な場合があります。
たとえば、Objective Cには参照カウントメモリ管理が含まれますが、Appleは、iOS/macOSリアルタイムオーディオコンテキスト内でメモリを割り当てることができるメソッドの使用を推奨していません。 $$$相当のコンサートホールのスピーカーをポップするライブパフォーマンスの音楽シンセ。
たとえば、グローバル「ヒープ」からの単一スレッドの汎用メモリ割り当て/割り当て解除について話している。すべてのCプログラマーは、malloc（）/ free（）の形式で知っています。
答えは、OS内で使用されるものと非常に似ていると思います。 Linuxカーネル。ここでの問題は、遅いですか？もちろん、O（log n）は高速です。それは常に速いですか？いくつかのアルゴリズムは、ルックアップには高速ですが、挿入/削除にはそれほど速くありません。また、他のアルゴリズムには、挿入/削除は高速ですが、ルックアップはそれほど高速ではありません。
たとえば、AVLとRed-blackツリーはどちらもO（log n）です。 kernel documentation を引用するには：
赤黒ツリーはAVLツリーに似ていますが、挿入と削除（ツリーのバランスをとるために最大で2回転と3回転）のリアルタイムの最悪の最悪のパフォーマンスを提供しますが、少し遅くなります（ただしO（log n））ルックアップ時間。
赤黒木を使用する場合、挿入/削除操作が大量にあり、すべてのアプリケーションに当てはまるとは限りません。
これにより、アルゴリズムの実行方法がわかります。塩のピンチは、それはアプリケーションに依存し、それを見つける方法はプロファイリングによってです。