問題タブ [buffered]

ビットマップをバッファに描画し、javascript を使用してビットマップを作成したいと考えています。理想的には、線、四角形などを描画してビットマップを作成し、必要に応じて画面にペイントする必要があります。返信とコードのヒントを提供していただきありがとうございます。

よろしく

ネットワーク経由でビデオ ストリームをブロードキャストできるようにする Android アプリケーションの最初の部分を開発しています。現在、次のように非常に直接的な方法でビデオを送信しています。

しかし残念ながら、それはあまり流動的ではありません。ソケット経由でデータ ストリームを送信する前に、データ ストリームをバッファリングしたいと考えています。私が試した方法の 1 つは、メディアを記録するために Android API を使用してストリームをファイルに書き込み、別のスレッドを使用してコンピューター上のサーバーにファイルをストリーミングすることです。

だから私の問題は次のとおりです。まだ書き込み中のファイルをソケットで送信するにはどうすればよいですか? BufferedInputStreamには読み取り用のブロッキング メソッドがないため、このようなことを試みましたが、成功しませんでした

しかし、私がそうしているとき、ネットワークがデータストリームよりも速い場合、私はすぐにループから抜け出します.

それを行うための「良い」方法はありますか？私はアクティブな待機を行うことについて考えましたが、特にモバイルの場合、それは良い解決策ではありません. 別の方法は、次のようなことです。

しかし、それは私にとってはかなり汚いように聞こえます...もっと洗練された解決策はありますか?

を回避するために、fstream出力バッファに直接書き込もうとしていmemcpyます。

次のコードが機能しないのはなぜですか？

Linux上で適切な長さの出力ファイルをコンパイル、実行、生成します。ただし、出力ファイルには正しいテキストが含まれていません。また、何らかの理由で、を含む2行をコメントアウトすると、str2長さがゼロの出力ファイルが生成されることに注意してください。

注：この例は回避しませんmemcpyが、機能する場合は、アプリケーションでを回避するのに役立ちmemcpyます。

2400x1800のバッファリングされた画像（多くのリソースを必要とすることはわかっています）を使用するアプリがありますが、90％以上の時間で完全に機能します。130 mbのRAMを使用し、CPUの5％を使用します。

問題は、10％の時間、大きなラグがあり、40〜50 mbのRAMしか消費せず、CPUの50％を使用することです。なぜ同じ記憶を食べなかったのですか？

コードを投稿する必要があることはわかっていますが、アプリは非常に大きいので、この特定の問題について少し話す可能性のあるものへのリンクが非常に役立ちます。

(ちょっと前置きが長くなってすみません)

後で実際の実行を高速化するために、大きなファイル全体 (>400MB) をバッファ キャッシュにプレフォールトするアプリケーションの開発中に、一度に 4MB を読み取ることが、一度に 1MB のチャンクのみを読み取る場合よりも顕著な利点があるかどうかをテストしました。驚くべきことに、実際には小さなリクエストの方が高速であることが判明しました。これは直感に反するように思えたので、より広範なテストを実行しました。

テストを実行する前に、バッファ キャッシュを消去しました (笑いのために、私もバッファ内のファイルで 1 回実行しました。バッファ キャッシュは、要求のサイズに関係なく 2GB/秒以上を提供しますが、驚くべきことに +/- 30% です)。ランダム分散）。
すべての読み取りは、同じターゲット バッファーを持つオーバーラップした ReadFile を使用しました (ハンドルは を使用して、または使用せずに開かれましFILE_FLAG_OVERLAPPEDた) FILE_FLAG_NO_BUFFERING。使用されているハードディスクはやや古いものですが、完全に機能しており、NTFS のクラスター サイズは 8kB です。ディスクは最初の実行後に最適化されました (6 つのフラグメントと非フラグメント、ゼロの差)。より良い数値を得るために、私はより大きなファイルも使用しました.以下の数値は1GBを読み取るためのものです.

結果は本当に驚くべきものでした：

したがって、これは、 2 クラスタの長さで 1 万件のリクエストを送信する方が、数百の大規模な連続した読み取りを送信するよりも実際には優れていることを示唆しています。送信時間 (ReadFile が返されるまでの時間) は、要求の数が増えるにつれて大幅に増加しますが、非同期完了時間はほぼ半分になります。
非同期読み取りが完了している間、カーネルの CPU 時間はすべてのケースで約 5 ～ 6% です (クアッドコアでは、実際には 20 ～ 30% と言うべきです)。これは CPU の驚くべき量です。忙しい待機時間も無視できます。2.6 GHz で 25 秒間 30% の CPU。これは、「何もしない」ためのかなりの数のサイクルです。

これをどのように説明できますか？ここにいる誰かが、Windows オーバーラップ IO の内部動作についてより深い洞察を持っているのではないでしょうか? それとも、ReadFile を使用して 1 メガバイトのデータを読み取ることができるという考えに、何か根本的な間違いがありますか?

特にリクエストがランダム アクセスの場合 (ランダム アクセスではない場合)、IO スケジューラがシークを最小限に抑えることで複数のリクエストを最適化できることがわかります。また、NCQ でいくつかの要求が与えられた場合に、ハードディスクが同様の最適化をどのように実行できるかを確認できます。
しかし、私たちは途方もなく小さな要求の途方もない数について話しているのです。

補足:明らかな勝者はメモリ マッピングです。私はメモリマッピングの大ファンなので、「当然のことながら」追加する傾向がありますが、この場合、「要求」がさらに小さくなり、OS が予測して実行する能力がさらに低下するため、実際には驚きます。 IO をスケジュールします。最初はメモリ マッピングをテストしませんでした。リモートでも競合できる可能性があると直感に反するように思えたからです。あなたの直感はこれで終わりです。

ビューを異なるオフセットで繰り返しマッピング/マッピング解除すると、実質的に時間がかかりません。16MB のビューを使用し、ページごとに 1 バイトを読み取る単純な for() ループですべてのページをフォールトすると、9.2 秒 @ ~111 MB/秒で完了します。CPU 使用率は常に 3% (1 コア) 未満です。同じコンピューター、同じディスク、すべて同じ。

また、Windows は一度に 8 ページをバッファ キャッシュにロードするように見えますが、実際には 1 ページしか作成されません。8 ページごとにフォールトすると、同じ速度で実行され、ディスクから同じ量のデータが読み込まれますが、「物理メモリ」と「システム キャッシュ」のメトリックが低くなり、ページ フォールトの 1/8 しか表示されません。その後の読み取りでは、ページが確実にバッファ キャッシュ内にあることが証明されます (遅延やディスク アクティビティはありません)。

(おそらく、 Memory-Mapped File is Faster on Huge Sequential Read と非常に、非常に遠い関係がありますか? )

もう少しわかりやすくするために、次のようにします。

アップデート：

を使用するFILE_FLAG_SEQUENTIAL_SCANと、128k の読み取りの「バランス」がとれているように見え、パフォーマンスが 100% 向上します。一方、これは 512k と 256k の読み取りに深刻な影響を与え (なぜだろうか?)、それ以外には実際の影響はありません。より小さいブロック サイズの MB/秒グラフは、間違いなくもう少し「均一」に見えますが、実行時間には違いはありません。

ブロックサイズが小さいほどパフォーマンスが向上するという説明も見つけたかもしれません。ご存じのとおり、非同期リクエストは、OS がリクエストを即座に処理できる場合、つまりバッファから (およびさまざまなバージョン固有の技術的制限により) リクエストを処理できる場合、同期的に実行される場合があります。

実際の非同期読み取りと「即時」の非同期読み取りを比較すると、 256kを超えると、Windows はすべての非同期要求を非同期的に実行することに気付きます。ブロックサイズが小さいほど、すぐに利用できない場合でも、より多くの要求が「すぐに」処理されます(つまり、ReadFile は単に同期的に実行されます)。明確なパターン（「最初の100リクエスト」や「1000以上のリクエスト」など）は分かりませんが、リクエストサイズと同期性には逆相関があるようです。ブロックサイズが 8k の場合、すべての非同期リクエストは同期的に処理されます。
バッファリングされた同期転送は、何らかの理由で非同期転送の 2 倍の速さです (理由はわかりません)。したがって、要求サイズが小さいほど、より多くの転送が同期的に行われるため、転送全体が高速になります。

メモリ マップド プレフォールトの場合、FILE_FLAG_SEQUENTIAL_SCAN によってパフォーマンス グラフの形状がわずかに異なります (少し後ろに移動した「ノッチ」があります) が、所要時間の合計はまったく同じです (これも驚くべきことですが、私にはわかりません)。それを助ける）。

更新 2:

バッファリングされていない IO により、1M、4M、および 512k リクエストのテストケースのパフォーマンス グラフは、最大値が 90 GB/s で、やや高くなり、より「スパイキー」になりますが、最小値も厳しく、1GB の全体的な実行時間は +/- 0.5 以内です。バッファリングされた実行の s (ただし、2558 を超える進行中のリクエストでは、ERROR_WORKING_SET_QUOTA が返されるため、バッファ サイズが小さいリクエストは大幅に高速に完了します)。発生するすべての IO は DMA 経由で実行されるため、測定された CPU 使用率はすべての非バッファリングのケースでゼロです。これは当然のことです。

もう 1 つの非常に興味深い観察結果FILE_FLAG_NO_BUFFERINGは、API の動作が大幅に変わることです。少なくともIO をキャンセルCancelIOするという意味では機能しません。バッファリングされていない進行中のリクエストでは、すべてのリクエストが完了するまで単純にブロックされます。弁護士はおそらく、関数が戻ったときに実行中のリクエストが残っていないため、関数がその義務を怠ったことについて責任を負うことはできないと主張するでしょう。は多少異なります。バッファリングされ、オーバーラップされた IO を 使用すると、単純にロープが切断され、実行中のすべての操作がすぐに終了します。CancelIO
CancelIO

もう 1 つの面白い点は、すべての要求が完了するか失敗するまで、プロセスを強制終了できないことです。OSがそのアドレス空間にDMAを実行している場合、この種のことは理にかなっていますが、それでも驚くべき「機能」です.

私は URL と URLConnection を読んできましたが、Buffered InputStream/OutputStream (文字ストリームの場合) と Buffered Reader/Writer (バイト ストリームの場合) の両方を使用して、URL と URLConnection を介してある ftp から別の ftp にファイルを転送できることを知っています。と思うのですが、どちらが使いやすいのでしょうか？ソース ftp は Windows 2003 OS で、宛先 ftp は Unix OS です。ソース ftp からのファイルは宛先 ftp で処理されるため、文字表現/ファイル形式は同じままである必要があります。

sencha touch モバイル アプリに表示するかなり長いリストがありました。リストの内容のせいで、アプリはかなり重かったのですが 、効率が大幅に向上したこの素晴らしいツールを見つけました。しかし、このライブラリに伴う問題は、最初の 70 項目が表示され、下にスクロールしても何も表示されません。対処した人いますか。私にお知らせください。

以下は、シミュレーションに役立つテストコードのサンプルです。

以下は、以下に示すように、ssh スクリプトを使用してデータ (ファームウェア バージョン) を取得する必要があるドライバー情報です。

これは、最初に「データ」変数ですべてのデータを読み取るために使用しているプログラムです。後で分割して必要な情報を取得できますが、データがないため、印刷データに印刷されます。

データを取得する際に私を修正してください。

バッファなし I/O と標準 I/O の違いは何ですか? read()、write()、close() の使用はバッファリングされていない IO であることを知っています。Printf と get はバッファリングされた IO です。また、大きなトランザクションにはバッファリングされた IO を使用する方がよいことも知っています。理由が分からないだけです。そして、この文脈で「バッファリング」という用語は何を意味するのでしょうか?

基本的に、私は加速度計のデータをtxtファイルにキャプチャしようとしています。コードはaccelデータを文字列に書き込み、変更されるたびに更新します。これは頻繁に行われます。データのログ記録を開始し、ファイルに書き込むことになっているトグルボタンを含めました。これはそれが奇妙になるところです。コードは、ファイルがすでに存在するかどうかを確認し、ファイルの最後に番号を追加して、古いデータを上書きしていないことを確認します。しかし、それはゴミや破損したデータでいっぱいのファイルを作成します。ファイルがすでに存在する場合は、ファイルに適切なデータが書き込まれることを確認しましたが、ファイルを作成する必要がある場合は、破損したファイルが作成されます。コードを以下に示します。ファイルの破損で何が起こっているのかわからない。

マニフェストで宣言しました

破損したデータを含むログファイルの例

＃EO'MyÎ＆¸Œ-`íÐïÇDêç³òß¼（1Þû'æÁ9Û™íb_CONSOLE・óZub™

どう考えているか教えてください。