問題タブ [buffer]

コストのかかるディスク I/O を回避するために、メイン メモリにキャッシュすることがポイントではないでしょうか。

ハード ドライブのスワップ領域に何かをキャッシュしている場合、ディスク I/O をどのように回避しますか?

SOコーデックによって解釈されたビデオを再生するには、JMFを使用できないJava APIが必要ですが、Javaコードで各フレームを取得したいと考えています。誰か知ってる？

非常に大きなテキスト ファイル (2 GB) を処理する必要があるため、1 行ずつ読み書きする必要があります。ofstream を使用して 2,300 万行を書き込むのは非常に遅いため、最初は大量の行のチャンクをメモリ バッファー (たとえば 256 MB または 512 MB) に書き込み、そのバッファーをファイルに書き込むプロセスを高速化しようとしました。 . これは機能しませんでした。パフォーマンスはほぼ同じです。ファイルの読み取りに同じ問題があります。I/O 操作が STL I/O システムによってバッファリングされることはわかっています。これは、ディスク スケジューラ ポリシー (私の場合は Linux の OS によって管理される) にも依存します。

パフォーマンスを向上させる方法について何か考えはありますか?

PS: プログラムがデータを処理している間にバックグラウンドの子プロセス (またはスレッド) を使用してデータ チャンクを読み書きすることを考えていましたが、これが価値があるかどうかはわかりません (主にサブプロセスの場合)。

C# を使用して開発しているアプリケーション用に、ある種のバッファー管理を開発する必要があります。

基本的に、アプリケーションは、デバイスが着信するたびにデバイスからメッセージを受信します (短時間に多数のメッセージが送信される可能性があります)。それらを管理された方法で処理できるように、ある種のバッファープールにそれらをキューに入れる必要があります。

メモリのブロックを 256 バイトのチャンク (すべてのメッセージはそれよりも小さい) に割り当て、バッファー プール管理を使用して、着信メッセージに使用できる使用可能なバッファーのプールと、処理する準備が整ったバッファーのプールを用意することを考えていました。 .

したがって、フローは「バッファを取得する」（処理する）「バッファを解放する」または「プールに残す」になります。また、バッファーがいついっぱいになるかを知る必要もあります。

潜在的に、常に次のバッファを取得するのではなく、バッファを「のぞき見」して、プール内の最も優先度の高いバッファが何であるかを確認する方法も必要になるでしょう。

これは .NET で既にサポートされていますか、それとも使用できるオープン ソース コードはありますか?

私は長年疑問に思っていた質問があり、誰かが私の心を休ませるために答えてくれることを望んでいました.

入力ストリーム (ファイル/ソケット/パイプなど) があり、受信データを解析したいとします。最も一般的なインターネット プロトコルのように、受信データの各ブロックが改行で分割されていると仮定しましょう。このアプリケーションは、html、xml、またはその他のスマート データ構造を解析することもできます。ポイントは、データが固定長ではなく区切り文字によって論理ブロックに分割されることです。区切り文字が表示されるのを待つためにデータをバッファリングするにはどうすればよいですか?

答えは単純に思えます: 全体に収まる十分な大きさのバイト/文字配列を用意するだけです。

しかし、バッファーがいっぱいになった後に区切り文字が来るとどうなるでしょうか? これは実際には、データの動的ブロックを固定サイズのブロックに収める方法に関する質問です。私は本当にいくつかの選択肢しか考えられません：

1. 必要に応じてバッファ サイズを増やします。これには、大量のメモリの再割り当てが必要になる可能性があり、特別に細工されたストリームによるリソースの枯渇につながる可能性があります (または、枯渇攻撃から身を守り、リソースを枯渇させようとする接続を切断する必要があるソケットの場合は、サービス拒否にさえつながる可能性があります...そして攻撃者は、保護をトリガーするために偽の特大のパケットを送信し始めます)。

2. 循環バッファーを使用して、古いデータの上書きを開始します。論理ブロックが不完全になるため、おそらく理想的な方法ではありません。

3. バッファがいっぱいになったら、新しいデータをダンプします。ただし、この方法では区切り文字が見つからないため、この選択は明らかに適切なオプションではありません。

4. 固定サイズのバッファを非常に大きくし、すべての着信論理データ ブロックがその境界内にあると仮定します...そして、いっぱいになった場合は、完全なバッファを論理ブロックとして解釈するだけです...

どちらの場合でも、論理ブロックが特定のサイズを超えることはないと想定する必要があると思います...

このトピックについて何か考えはありますか？readLine()高水準言語はストリーム メソッドで何らかのバッファリング メカニズムを提供するため、明らかに方法が必要です。

これを解決する「最善の方法」はありますか、それとも常にトレードオフがありますか? ある種のパーサーを書く必要があるたびにこの質問に悩まされていたので、このトピックに関するすべての考えとアイデアに本当に感謝しています。

ログ ファイルを読んでいますが、すべての行をすぐに処理したいわけではありません。キュー/バッファを使用して、処理されるのを待っている間に行を保存しています。

このキューは定期的に特定の行をスキャンされます - それらが見つかると、それらはキューから削除されます (行はどこにでもあります)。特定の行が見つからない場合、行はキューの先頭から 1 行ずつ取り出されて処理されます。

したがって、キューには次のものが必要です。

• サイズ変更可能（またはその印象を与える）
• どこからでも要素を削除する
• 要素が追加されている (常にキューの最後にある)
• すばやくスキャン
• パフォーマンスに応じて、最後のスキャンで到達した場所のポインタを用意してください。

Java や API の経験がほとんどないときに最初にコードを書き、ArrayList が機能することを知っていたので (必ずしもそれが最適なオプションだったというわけではありません)、単に ArrayList を使用しました。

処理する必要のあるログがますます多くなり、パフォーマンスが低下しています。この状況で使用するためにどのコレクションをお勧めしますか? 自分で書く可能性も常にあります。

ありがとう

以下でCharBufferaより a を好む理由はありますか?char[]

対。

( inaReaderとoutaはどこにありWriterますか)?

シングルスレッドで使用するには、Java でバイト バッファ クラスが必要です。O(1) の償却コストで、バッファーの後ろにデータを挿入し、前にデータを読み取ることができるはずです。バッファーは、例外などをスローするのではなく、いっぱいになったときにサイズを変更する必要があります。

自分で作成することもできますが、これが標準の Java パッケージにまだ存在していなければ非常に驚きます。

あなたは何をお勧めします？

MiniBufExplorerを試しましたが、通常、いくつかのウィンドウに表示されたり、完全に閉じたりします。私が欲しいのは、インクリメンタルサーチを備えたLustyJugglerのようなもので、Emacsのバッファーを切り替える方法です。確かにこのようなスクリプトはありますか？

特定のファイル タイプ (およびそれらのファイル タイプのみ) を保存するときに Emacs でタブ化を解除することに基づいて、バッファーの変更を開始するときに C++ ファイルをタブ化解除するフックを実行したいと思います。ロード時にバッファを非タブ化するフックを追加しようとしましたが、emacs の起動時に自動ロードされるすべての書き込み可能なファイルが非タブ化されます。

(なぜ私がこれを行っているのか不思議に思われる方のために説明すると、それは、私が働いている場所で、ファイル内でのタブの使用が義務付けられているためです。私は喜んでこれに準拠しています。問題は、行が多すぎる場合にファイルをマークアップすることです。長いですが、正規表現は行が占めるスペースではなく、行の文字数に一致します. 行に 4 つのタブがあると、私の 132 文字の制限をはるかに超える可能性がありますが、行は適切にマークされません. したがって、自動的にタブ化および非タブ化する方法が必要です。)