「50% 長く」とはどのように言いますか? 私たちは分を話しているのですか、それとも秒を話しているのですか?
数秒の場合は、単に同期エラーである可能性があります (clock_t
実際の時間が数百分の 1 秒以上変化することなく、2 秒が最大 2 秒異なる場合があります)。
しかし、私の推測では、より長い時間を見ていると思います。コードを見なくても、「リークした」メモリを割り当てることで、メモリヒープを「準備」し、後で情報をより高速に取得できると思われます。
つまり、メモリを最適に管理していない可能性があり、メモリを事前に割り当てて再利用することでメリットが得られる可能性があります (「オブジェクト プール」)。
メモリ ヒープの「プライミング」とは、通常、ヒープ メモリを追跡するメモリ マネージャに対してメモリ割り当てが要求されることを意味します。より単純なケースでは、リンクされたリストを使用します。ガベージ コレクターがなくても、、などの背後にあるメモリ マネージャーがあります (さらに言えば)。MMは、オペレーティング システムに大きなチャンクを要求してから、それをアプリケーションに渡すことによって、および/または OS によってより適切に/より速く処理される可能性がある要求で行う要求を「微調整」することによって動作できます。たとえば、OS は通常、メモリをページ単位で「認識」します。malloc
free
realloc
new
1K、4K、64K のいずれかです。自分自身に 10 バイトの文字列を 50 個割り当てると、別のページに配置され、大量のメモリが浪費される可能性があります。10 バイトの最初の要求を確認した MM は、おそらく 4096 を割り当ててから、それらを 10 バイト単位で分割します。
ここで (私はここで手足を踏み出します!)、アプリケーションがページ全体に等しいメモリを 10 個のチャンクで割り当てる必要があるとします。プログラム自体が小さなオーバーヘッドを必要とするため、最初のヒープ割り当ては 1/4 ページです。
それでは、先に進み、10 個のチャンクを割り当てます。最初の 6 つは、部分的に空のページ 0 に収まります。次の 4 つは、新しいページ、ページ 1 の新しい割り当てを要求します。
割り当てが完了すると、チャンクが 2 つの異なるページに存在することに気付かずに、データをチャンクとの間でジャグリングし始めます。OS、コンパイラ、最適化、天気予報によっては、これらの操作でオーバーヘッドが発生する可能性があります。
ここで、ページの 4 分の 3 を割り当ててリークするとします。次に、最初のチャンクを割り当てると、それはページ 0 に収まらず、最初の (および残りの 9 つの) チャンクはすべてページ 1 に収まります。-O3 最適化が同一ページ データ アクセスを悪用する場合、コンパイラに依存するパフォーマンスの向上が発生します。
これはアドホックな仮説にすぎないことに注意してください。私にはもっともらしいように見えますが、それは実際には何かを保証するものではありません:-)
libc の標準メモリ管理 (他にもあります) の詳細はこちら
http://www.chemie.fu-berlin.de/chemnet/use/info/libc/libc_3.html#SEC27
C++ 用の Google のツールもチェックしてください。