場所とルール！ host newを使用してC ++コードを最適化する

オブジェクトの後にオブジェクトを作成する場合、動的メモリ割り当てなどの「些細なこと」に注意を払わないことがよくあります。 コピーとシリアル化に加えて、ヒープから新しいメモリを割り当てると、C ++の速度の利点が徐々に無効になります。 大切な新しいものをより集中的に使用すればするほど、メモリが不足し、断片化され、あらゆる方法でリークが発生するため、アプリケーションにとっては難しくなります。 便利ですが、パフォーマンスSTLコンテナーには暗黙的に危険です。ベクター、ストリング、デック、マップは、すでにこの運命に陥っています。 大量の小さなオブジェクトの割り当ての速度を落とすのは特に残念です。 しかし、スタック上のそのようなオブジェクトのメモリの配置を処理する方法がありますが、特別なデータクラスで実装の詳細を隠します。 これは、新しい配置のメカニズムに役立ちます。これは、ヒープから頻繁かつ少量のメモリ割り当てでいっぱいのアプリケーションを最適化するための比類のない方法です。



前回のレッスンでは、驚くべきことを行いました。実行時に計算され、動的に入力される型の値を含むコンテナとしてC ++オブジェクトを操作しました。 オブジェクトへの入力時に、実際のデータ型を参照するstd :: shared_ptrを介してコピーオンライトアドオンを積極的に使用しました。 また、任意のデータ初期化にメモリを動的に割り当て、任意の型の新しいデータが必要になるたびにnewを呼び出すことも理解されました。



このアプローチには利点があります。 データは複数のオブジェクト間で共有され、コピーが遅延する可能性があります。 原則として、データ型について事前に何も知ることはできません。 ただし、この方法には多くの欠点もあります。これは、非常に大きい可能性のあるオブジェクトに対して、コピーオンライトが原則として使用されるためです。



最初の欠陥はすぐに明らかになります。 大量の動的メモリ割り当ては、プログラム実行、特にnewを介した大量の暗黙的なメモリ割り当てを大幅に遅くします。 はい、std :: stringとstd :: vectorの両方を知っています。多くの場合、プログラマに確認することなく、メモリの再割り当てを開始し、次々と新しいものを呼び出します（そして、std :: vectorへのデータの移動についても説明します）。 C ++開発の優れた専門家は、標準コンテナのこれらの面白い機能を常に知っており、新しいメモリセグメントを割り当てるための不必要な費用を回避する方法を理解しています。 純粋なCが常に適しているのは、メモリを使用した作業が透過的に実行されたためです。C++では、メモリを使用した暗黙的な作業のすべてのケースを常に念頭に置く必要があります。



2番目の欠点は最初の欠点です。 メモリの小さなセグメントを大量に頻繁に割り当てると、メモリのひどい断片化が発生し、たとえば同じstd ::ベクターまたはstd ::文字列を初期化するために、かなり小さなメモリブロックを1つのピースに割り当てることができなくなります。 その結果、明らかな理由もなくbad_allocを取得します。 必要以上のメモリがありますが、メモリが非常に断片化されている状況では、小さなサイズの連続ブロックを割り当てることはできません。



したがって、スタックに簡単に配置できるint64_tに匹敵する小さなオブジェクトには、別のデータ処理技術を使用できます。 このようなオブジェクトは値渡しできます。1つまたは2つのレジスタが簡単にコピーされるため、最初の変更まで遅延することなく、何度でもコピーできます。



同時に、実装時にデータの詳細を宣言する慣行から逸脱するべきではありません。 ただし、何かを犠牲にする必要があります。データの正確なサイズをバイト単位で事前に知る必要があります。 通常のデータポインタと一緒にオブジェクトデータを配置するために、クラスにバッファを保持するために必要になります。 より詳細に。

ファーストクラス

外側では、ほとんど何も変わりません。 APIオブジェクトを提供するすべての同じクラス。 このクラスには、前方宣言によって宣言されたクラスのデータへのリンクが含まれており、実装の詳細でレンダリングされます。 このため、クラスフィールドにこの型のオブジェクトを宣言することはできませんが、単純なポインターでデータ型を参照し、同じオブジェクトにオブジェクトデータを格納するためのバッファーを事前に設定できます。 たとえば、スタック上にオブジェクトが作成された場合、すべてのデータはオブジェクトの一部としてスタックに保存されます。 次に、すべてが適切に配置されるように例を考えます。

class object { public: ... protected: //    class data; //       static const size_t max_data_size = N; private: //    data* m_data; //  ,     char m_buffer[max_data_size]; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードでは、実装でデータを隠すというイデオロギーを続けています。クラスデータについて知っているのは、クラスの名前とデータへのポインターの存在だけです。 ただし、現在はヒープ内でメモリ不足を回避する機会があります。 C ++の用語では、クラスはフィールドの形式でデータを保存します。 実際、データはm_bufferバッファーに配置されます。m_bufferバッファーは、クラスが作成されたときに既に割り当てられたメモリです。 バイトバッファにデータを配置する方法の詳細を説明するだけです。

新しいホスティング

原則として、作成されたオブジェクトを配置するための既製のメモリ領域を指定する機能として、new演算子のこのような有用なプロパティを考える人はほとんどいません。 必要なのは、割り当てられたバッファに任意のタイプのオブジェクトを作成するために、新規（m_buffer）を書き込むことだけです。 簡単に聞こえますが、最大バッファサイズを事前に指定するという高い価格を支払うことを覚えておく必要があります。 それだけでなく、バ​​ッファのサイズはヘッダーファイルに収まり、API宣言に明示的に関与します。



しかし、我々はスピードで勝ちます。 初期化ごとにヒープにデータを割り当てることで、Javaに遅れをとるリスクが発生した場合、すべてのデータをスタックに配置することで、純粋なsi速度（C ++を除くほとんどすべての高レベル言語で達成不可能な速度）が得られます。 同時に、抽象化のレベルは非常に高く、通常のC ++オブジェクトにAPIを構築し、実装の詳細を隠します。 唯一の制限は、設定したサイズです。 実装内のデータクラスのフィールドセットを簡単に変更することはできなくなりました。サイズを常に覚えておく必要があります。 さらに、実装に記述されているデータのサイズをチェックして、ヘッダーファイルで指定されているデータに準拠する必要があります。 ライブラリのアセンブリがヘッダーファイルのバージョンと異なる場合があるのは、たとえばさまざまなソースから受信する場合などです。 そのようなチェックが、newを配置することによって準備されたメモリにオブジェクトを作成するように見える方法の例を見てみましょう。

 object::object() : m_data(new(m_buffer) object::data) { static_assert(sizeof(object::data) <= max_data_size, "..."); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、static_assertはコンパイル段階で実際に実行されるため、m_dataはオブジェクト::データ用にm_bufferバッファーに十分なメモリがある場合にのみ初期化されます。 同様に、オブジェクトクラスの下位クラス（たとえば、flower）では、データが基本クラスの実装に格納されるため、データが指定されたバーを超えてはなりません。

 flower::flower(std::string const& name) : object(new(get_buffer()) flower::data(name)) { static_assert(sizeof(flower::data) < max_data_size, "..." ); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

明らかに、これには、オブジェクト::データ*からオブジェクトの保護されたコンストラクターと同様に、基本クラスのm_bufferアドレスを取得するためにget_buffer（）protectedメソッドが必要です。 前のリリースのように、基本クラスのデータから相続人のデータを継承するため、flower :: data *はobject :: data *と互換性があります。 セキュリティのために、object :: data *から基本コンストラクタに追加する価値があります。以前に割り当てられたバッファのアドレスが渡されることを確認します。

 object::object(object::data* data_ptr) { if (static_cast<void*>(data_ptr) != static_cast<void*>(m_buffer)) throw some_exception(...); m_data = data_ptr; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、以前と同様に、通常のクラスオブジェクトを操作することで動的型付けをエミュレートできます。 たとえば、次のように：

 object rose = flower("rose");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

大きなデータオブジェクト

データサイズが指定された最大値を超えるオブジェクトをどうするかを見つけることは残っています。 実際、ここのすべては非常に簡単です。 copy_on_write <data :: impl>のサイズが制限に収まるだけで十分です。これは、本質的にstd :: shared_ptr <data :: impl>のアドオンです。ここで、implは任意のサイズのデータ​​クラスの実装です。 std :: shared_ptr <data :: impl>のサイズは、data :: implクラス自体のオブジェクトのサイズに依存しないため、値によるストレージから参照によるストレージへの移行でデータを格納する普遍的な方法を取得します。

 class huge { public: ... protected: class data; }; class huge::data { public: ... protected: class impl; private: copy_on_write<impl> m_impl; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、動的型付けを使用するオブジェクト用の単一APIの問題の解決策から脱却し、新しい配置による最適化の別の例を考えてみましょう。

copy_on_write ::フラッシュバック

誰かが以前のリリースをスキップした場合、copy_on_writeクラスはコピー最適化でデータを保存するためのテンプレートクラスです。 ポインターをエミュレートするこのクラスには、constおよびnon-constの場合のトリッキーなoperator->オーバーロードがあります。 オブジェクトをコピーするとき、高価なコピーを引き起こすことなく同じデータを参照します。 ただし、データを潜在的に変更するデータクラスの非定数メソッドを呼び出すとすぐに、現在のオブジェクトのデータのコピーをデタッチします。 簡素化された実装は次のようになります。

 template <typename impl_type> class copy_on_write { public: copy_on_write(impl_type* pimpl) : m_pimpl(pimpl) { } impl_type* operator -> () { if (!m_pimpl.unique()) m_pimpl.reset(new impl_type(*m_pimpl)); return m_pimpl.get(); } impl_type const* operator -> () const { return m_pimpl.get(); } private: std::shared_ptr<impl_type> m_pimpl; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、組み込みバッファの最大データサイズを選択する場合、フィールドとしてcopy_on_writeを含むクラスのサイズを考慮する価値があります。

データフィールド

ホストnewを介して最適化する最も強力な方法は、SQLクエリの選択レコードのフィールドを使用することです。 サンプルは、整数や実数から文字列や配列まで、さまざまなタイプのデータセットを要求します。 データ自体は動的に取得され、データベース側から取得されたフィールドタイプは動的型付けエミュレーションで初期化する必要がありますが、すべてのレコードには、各レコードの合計データサイズを決定できる同じフィールドタイプのセットが含まれています。 これにより、レコードフィールドにメモリを1回だけ割り当てることができ、選択した各レコードに含まれるフィールドのタイプに応じてサイズが計算されます。 また、単一のユニットとしてすべてのレコードに一度メモリを割り当てることも可能ですが、原則として、レコードを取得した後、フィルタリングや並べ替えを含むあらゆる種類の操作が実行されるため、後続の操作の便宜のためにレコード自体をコピーオンライトオブジェクトとして記述することは理にかなっています。 各フィールドにヒープからメモリを割り当てるのは不当に高価です。



これは、宣言を単純化し、データクラスから直接copy_on_writeを使用した場合のレコードクラスの外観です。

 class record { public: record(std::vector<field::type> const& types); ... protected: class data; private: copy_on_write<data> m_data; }; class record::data { public: data(std::vector<field::type> const& types); ... private: std::vector<char> m_buffer; std::vector<field*> m_fields; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、説明を簡単にするために、フィールドタイプのベクトルstd :: vector <field :: type>、enum値の配列が導入されています。 実際、この配列は、boost :: fusionを介して引数から型指定するか、Boost.Preprocessorを使用して、任意の型の引数から型オブジェクトの汎用オブジェクトの配列をダイヤルする必要があります。 各レコードのヒープからメモリを単一に割り当てるメカニズムは、今では重要です。

 record::data::data(std::vector<field::type> const& types) : m_buffer(field::calc_size(types)), m_fields(types.size()) { size_t offset = 0; std::transform(types.begin(), types.end(), m_fields.begin(), [&offset](field::type type, field*& field_ptr) { field_ptr = new(m_buffer + offset) field(type); offset += field::size(type); } ); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、field :: sizeは渡されたfield :: typeからデータのサイズを計算し、field :: calc_sizeはすでにstd :: vector <field :: type>として渡されたレコードタイプのセット全体に必要な合計サイズを計算しています。



フィールドフィールドは、基本的に動的コンテンツのコンテナであるオブジェクトタイプと同様に実装されます。 ほとんどの型：int64_t、bool、doubleはスカラーであり、値によって格納されます。 std ::文字列型も値で保存できますが、文字列データがほぼ確実にヒープに保存され、動的に割り当てられることを考慮する価値があります。 特定の長さの特定のvarcharをサポートする場合、ほとんどの場合、固定長の文字の配列を持つ独自の型copy_on_writeが必要になります。



さまざまなタイプのフィールドは、オブジェクトクラスから継承されたさまざまなタイプのオブジェクトに似ています。 enumを使用することもできませんが、型に直接結び付けられますが、原則として、SQLクエリの結果を解析するには、すべてのフィールド型が事前にわかっているデータのバイトパケットを逆シリアル化する必要があります。したがって、enumには制限がありません。 さらに、メタプログラミングは気弱な人向けではないため、ここではMPLとBoost.Fusionを検討しません。



新しいホストを使用する最後の重要な側面、つまりC ++の同じタイプのオブジェクトのプールについては触れていません。

同じタイプのオブジェクトのプール

前と同様に、動的メモリ割り当てを最適化しています。 オブジェクトプールとは何ですか？ これは、特定のタイプを初期化するために大勢の人によって事前に割り当てられたブランクの配列です。 ある意味では、上記のレコードはフィールドオブジェクトのプールでした。 また、高レベル言語（C＃、Python、Java）で作業している場合、オブジェクトのプールに出会った可能性があります。これらは、準備されたメモリセグメントを使用して、オブジェクトを配置する新しいオブジェクトを割り当てます。実際には、タイプはオブジェクトです。 プールオブジェクトの1つが不要になった後、つまり、参照されなくなった後、すぐに初期化解除されるか、ガベージコレクター、ガベージコレクター、所有者のいない商品を削除するための特別なメカニズムの次のバイパスの形で悲しい運命を待っています。 一般的に、プール内のオブジェクトの初期化解除はその弱点です。 しかし、通常はすでに初期化されているか、初期化の準備ができているオブジェクトの迅速な選択を取得します。 オブジェクトタイプに基づいて、参照カウントによる初期化解除とガベージコレクターを備えた本格的なオブジェクトプールを作成すると、JavaまたはPythonが得られます。 そのようなものが必要な場合、庭を囲い、ごみ収集で既製の言語を取るべきではないでしょうか？ ただし、同じタイプのオブジェクトの最適化のために、事前に大量のメモリセグメントを割り当てる必要があり、タスクが実際に特定の基本クラスを持つ多数のオブジェクトの大量初期化を必要とする場合、オブジェクトのプールにより、大量の動的メモリ割り当てを回避できます。



理解するには、明確で応用的な説明が必要です。 レコードのプールを使用したSQLクエリの結果として実際にフェッチするのはどうですか？ これにより、サンプルレコードオブジェクトを構築するためのメモリ割り当ての質量が最適化されます。

 class selection { public: selection(std::vector<field::type> const& types, size_t row_count); ... protected: class data; private: copy_on_write<data> m_data; }; class selection::data { public: data(std::vector<field::type> const& types, size_t row_count); ... private: std::vector<field::type> m_types; std::vector<char> m_buffer; std::vector<record> m_rows; }; selection::data::data(std::vector<field::type> const& types, size_t row_count) : m_types(types) { if (!row_count) return; m_rows.reserve(row_count); size_t row_data_size = field::calc_size(types); m_buffer.resize(row_count * row_data_size); char* offset = m_buffer for (size_t i = 0; i < row_count; ++i) { m_rows.push_back(record::inplace(offset, types)); offset += row_data_size; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

record :: inplaceは、本質的に、ヒープではなく、指定されたアドレスにレコードデータを作成します。

 record record::inplace(void* address, std::vector<field::type> const& types) { return record(new(address) record::data(types)); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

初期化と特別なデストラクタを備えたレコードコンストラクタが必要です。詳細は後で説明します。 レコードを初期化するこのオプションにより、以前のバージョン、つまりcopy_on_writeフィールドのみを含むクラスの形式でレコードを使用することができなくなります。 ヒープ上のデータの動的な割り当てに冷静に頼って、必要に応じてレコードを切り替えることはできません。 一方、大規模なデータセットを使用すると、パフォーマンスが大幅に向上します。 ただし、新しい投稿には注意が必要なキャッチがあります。

明示的なデストラクタ呼び出し

警告

誰かが最後まで読んだり、斜めに読んだりしない習慣がある場合-非常に無駄です。 この重要なセクションをスキップすることで、メモリリーク（大量のメモリリーク）を発生させることができます。

ホストnewを使用する場合、もう1つ「しかし」-削除は何もしないので、デストラクタを手動で呼び出す必要があります。 したがって、事前に準備されたメモリに割り当てられたデータを含むクラスは、デストラクタ内のメモリに作成されたクラスのデストラクタを明示的に呼び出す必要があります。 したがって、クラスデストラクタオブジェクト::〜オブジェクトは、オブジェクト::データ::〜データデストラクタを明示的に呼び出す必要があり、レコード::データ::〜データデストラクタは、フィールドごとに1つのフィールド::〜フィールドデストラクタを呼び出す必要があります。 これがどのように発生するかを明確に示すために、オブジェクトクラスをより詳細に説明します。

 class object { public: object(); virtual ~object(); ... protected: class data; char* get_buffer(); object(data* derived_data); static const size_t max_data_size = N; private: data* m_data; char m_buffer[max_data_size]; }; object::object() : m_data(new(m_buffer) data) { static_assert(sizeof(data) <= max_data_size, "..."); } object::~object() { m_data->~data(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

データクラスのデストラクタは仮想として記述する必要があるため、object :: dataの継承者が使用されているかに関係なく、データの初期化解除は成功します。



また、コンストラクターとコピー演算子、および移動を再定義する必要があります。これは、自動生成されたコンストラクターに満足したcopy_on_writeの場合とは異なり、ここでは各オブジェクトが単純なポインターでデータ領域を参照するためです。 したがって、デフォルトの動作を修正します。

 object::object(object const& another) : m_buffer(max_data_size), m_data(another.clone_data_at(m_buffer)) { } object& object::operator = (object const& another) { destruct_data(); //     m_data = another.clone_data_at(m_buffer); return *this; } object::data* object::clone_data_at(void* address) { return m_data->clone_at(address); } //      //      object::data* object::data::clone_at(void* address) { return new(address) data(*this); } void object::destruct_data() { m_data->~data(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、新しいdesctuct_data（）メソッドがデストラクタオブジェクト::〜オブジェクトで要求されています。 一度尋ねると、彼のための場所があることを意味します。 コンストラクターと移動演算子の場合、動作は同様です。

 object::object(object&& another) : m_data(another.move_data_to(m_buffer)) { } object& object::operator = (object const& another) { destruct_data(); //     m_data = another.move_data_to(m_buffer); return *this; } object::data* object::move_data_to(void* address) { return m_data->move_to(address); } //      //      object::data* object::data::move_to(void* address) { return new(address) data(std::move(*this)); } object::~object() { destruct_data(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、メモリリークの危険性はなくなります。 APIユーザーは落ち着いて開発できます。

ヒープ上の新規ホストと新規ホストのホスティング

既にお気付きのように、host newを使用するクラスは実装がはるかに困難です。 準備されたメモリにオブジェクトを配置する手法で実装されたクラスを使用するすべての側面を徹底的にテストする必要があります。 通常、クラスの通常の新しいものの複雑さは、スマートポインターをラップすることになります。 次に、データ型の最大サイズを明示的に指定することで動的型付けのエミュレーションでさえ複雑になる場合、どのような利点がありますか？



速度の向上。 より便利なC＃、Java、Pythonと比較したC ++の力は、実行速度にあります。 ここでは、新しいオブジェクトのヒープに移動しないため、最高速度に達します。 また、メモリの断片化を回避して、将来アプリケーションの速度を落とさないでください。 断片化された記憶はチーズのようなものです。穴がいっぱいで、これらの穴の大きさでオレンジを詰め込むことができますが、実際にはオレンジはどの穴にも収まらず、それぞれが小さすぎます。 そのため、連続メモリのセグメントを必要とするstd :: vectorおよびstd :: stringは、要素を再配布するときにいつかstd :: bad_allocを取得できます。

標準ライブラリの新しいホスティング

記事の冒頭でstd :: vectorにnewを配置することをお約束しましたか？ そのため、std :: vectorのすべての要素コンストラクターは、準備されたメモリで呼び出されます。 また、デストラクタは要素に対しても積極的に呼び出されます。 これは、intやcharなどの単純なPOD型のベクターでは重要ではありませんが、std :: vectorを強調したい場合、customに重要なデフォルトコンストラクターとそれほど重要ではないコピーコンストラクターがある場合、そうしないと多くの問題が発生しますstd :: vectorがそのデータをどのように処理するかを理解します。



では、ベクターにサイズ変更を要求するとどうなりますか？ まず、ベクターは必要なバイト数をまだ予約していないように見えます（ベクターは常にマージン付きのバッファーを割り当てます）。その後、新しいバッファーを割り当てます。 すべての既存の要素は、移動コンストラクターによって、対応するアドレスにnewを配置することにより、新しいバッファーに転送されます。 その結果、すべての要素が配置されます。 その後、ベクトルは必要な数の要素を配列の最後まで取得し、新しいデフォルトのコンストラクターを配置して各要素を作成します。 また反対方向-要素の数を減らすと、要素を削除するときにデストラクタが「手動で」発生します。



std :: vectorとは異なり、std :: stringコンテナは、コンストラクタやデストラクタを必要としないcharを常に格納するという理由だけで、新しい配置を処理しません。 ただし、標準ライブラリの多くのコンテナ：deque、list、map、および任意のデータを格納するためのその他のクラステンプレート-実装の新しいホスティングを積極的に使用します。



newをハックのようなものと考える必要はありません。指定されたメモリのコンストラクタでオブジェクトを初期化できる本格的な言語機能です。 この操作は、割り当てられたバイトブロックが特定のタイプ（通常は構造体）へのポインターとして宣言され、このメモリブロックでのさらなる作業がこのタイプのAPIによって実行された、古いC言語のトリックに似ています。

結果は何ですか？

もちろん、必要に応じて新しいホスティングを使用する機能は、それが本当に必要な場合にのみ、効率的かつ正当な理由で、すぐには実現しません。 それらのいくつかは、予備的な最適化の害によって最後まで打ち負かされていますが、反対に、他の人は、記事を読んだ後に、必要な場所と必要でない場所に新しい（m_buffer）を埋め込むように急ぎます。 時間が経つにつれて、両方が黄金色になります。



メソッドの本質は単純です-クラスオブジェクトを準備されたメモリに配置することが可能であり、必要な場合、いくつかの単純なルールを覚えていれば、これを行うのは比較的簡単です。

• オブジェクトが存在する間、メモリは常に存在する必要があります。メモリが摩擦されると、オブジェクトは壊れたメモリセグメントを参照し始めます。
• ホストnewによって割り当てられたオブジェクトのクラスデストラクタは手動で呼び出す必要があります。これは悲しいことですが、deleteはメモリをポインタで処理しません。

他のすべては、開発者の正確さと無限の想像力によってのみ制限されます。 それはあなたです。







Hacker Magazine＃190で最初に発行されました。

投稿者：Vladimir Qualab Kerimov 、リーディングC ++開発者、Parallels



ハッカーを購読する

• サイト資料
• 紙版
• iOS / iPadのハッカー
• Androidのハッカー