問題タブ [bytebuffer]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
java - Java の無限の ByteBuffer
私は、大量の情報を圧縮してバッファにバイト単位で保存するプログラムに取り組んでいます。ByteBuffer
最終的なサイズがわからないので使えません。
これを実装するより良い方法は何でしょうか?
java - Java の ByteBuffer のディープ コピー duplicate()
java.nio.ByteBuffer#duplicate()
古いバッファの内容を共有する新しいバイト バッファを返します。古いバッファのコンテンツへの変更は新しいバッファに表示され、その逆も同様です。バイト バッファのディープ コピーが必要な場合はどうすればよいですか?
java - ByteBuffer.allocate() と ByteBuffer.allocateDirect() の奇妙なパフォーマンス曲線の違いの理由
私は、ダイレクト バイト バッファで最適に機能するいくつかの -to- コードに取り組んでいます - 長寿命で大きい (1 接続あたり数十から数百メガバイト) SocketChannel
。対パフォーマンスのベンチマーク。SocketChannel
FileChannel
ByteBuffer.allocate()
ByteBuffer.allocateDirect()
その結果には、うまく説明できない驚きがありました。以下のグラフでは、256KB と 512KB でByteBuffer.allocate()
転送実装の非常に顕著な崖があり、パフォーマンスは最大 50% 低下しています。のパフォーマンスの崖も小さいようですByteBuffer.allocateDirect()
。(%-gain シリーズは、これらの変化を視覚化するのに役立ちます。)
バッファ サイズ (バイト) と時間 (MS)
ByteBuffer.allocate()
との間の奇妙な性能曲線の差はなぜByteBuffer.allocateDirect()
ですか? カーテンの後ろで何が起こっているのですか?
ハードウェアとOSに依存する可能性が非常に高いため、詳細は次のとおりです。
- デュアルコア Core 2 CPU を搭載した MacBook Pro
- インテル X25M SSD ドライブ
- OS X 10.6.4
ソースコード、ご要望に応じて:
java - Javaでのバイト配列から29ビット整数への最速かつ最も効率的な変換
AMFでは29ビット整数が一般的であるため、既知の最速/最高のルーチンを組み込みたいと思います。現在、2つのルーチンがライブラリに存在し、ideoneでライブテストできます。http
:
//ideone.com/KNmYT
クイックリファレンスのソースは
次のとおりです。
java - ReadableByteChannel.read(ByteBuffer dest) の読み取りは 8KB に制限されています。なんで?
私はいくつかのコードを持っています:
ReadableByteChannel
a から aに読み込みByteBuffer
、- 転送されたバイトを記録し、
- 数十から数百ミリ秒休止し、
ByteBuffer
をに渡しWritableByteChannel
ます。
いくつかの詳細:
- どちらのチャネルも TCP/IP ソケットです。
- 合計接続読み取りサイズは数十メガバイトです。
- ソース ソケット (
ReadableByteChannel
からバイトを取得している) が同じマシン上にある。 - HP DL380s 上の Debian Lenny 64 ビット
- Sun Java 1.6.0 アップデート 20
問題は、 ByteBuffer がどれだけ大きく割り当てられていても、 または のいずれかで.allocate()
、.allocateDirect()
ByteBuffer に読み取られるバイト数が 8KB で最大になることです。私のターゲット ByteBuffer サイズは 256KB です。これはごく一部 (1/32) しか使用されていません。約 10% の時間で 2896 バイトしか読み込まれません。
OS の TCP バッファ設定を確認しましたが、問題ないようです。これは、バッファ内のバイト数に関する netstat のレポートを見ることで確認できます。両方とも、ソケット バッファ内に 8KB を超えるデータがあります。
ここで際立っているのは、TCP と TCP6 の混在ですが、それは問題ではないと思います。上記の出力では、私の Java クライアントはポート 53404 にあります。
遅延よりも帯域幅を優先するようにソケットのプロパティを設定しようとしましたが、変更はありません。
の値をログに記録するとsocket.getReceiveBufferSize()
、一貫してわずか 43856 バイトと報告されます。思ったより小さいですが、それでも 8KB を超えています。(これはまた、私が予想していたであろう非常に丸い数ではありません。)
ここで何が問題なのか、私は本当に困惑しています。理論的には、知る限り、これは起こるべきではありません。ストリームベースのソリューションに「ダウングレード」することは望ましくありませんが、ソリューションが見つからない場合は、ストリーム ベースのソリューションに移行します。
私は何が欠けていますか?修正するにはどうすればよいですか?
java - ByteBuffer の内容を比較しますか?
Java で 2 つの ByteBuffers の内容を比較して等しいかどうかを確認する最も簡単な方法は何ですか?
java - ByteBuffer をシリアライズする方法
RMI を使用してネットワーク経由で java.nio.ByteBuffer を送信したいのですが、ByteBuffer はシリアライズできません。次のカスタムクラスを試してみましたが、役に立ちませんでした:
}
クライアントは依然としてシリアル化不可能な例外を受け取ります。何か案は?
ありがとう
java - ByteBuffer から OGG vorbis データをデコードするにはどうすればよいですか?
これまでに作成したライブラリには、ファイルまたはInputStream
. OGG vorbis データがByteBuffer
あり、最初にファイルに書き込むことなく PCM にデコードする必要があります。
java - ByteBuffer/IntBuffer/ShortBuffer Java クラスは高速ですか?
私はAndroidアプリケーション(明らかにJavaで)に取り組んでおり、最近UDPリーダーコードを更新しました。両方のバージョンで、いくつかのバッファーをセットアップし、UDP パケットを受信します。
最初のバージョンでは、一度に 1 バイトずつデータをまとめました (実際には 16 個の PCM オーディオ データです)。
更新されたバージョンでは、私が始めたときには知らなかったいくつかのクールな Java ツールを使用しました。
どちらの場合も、「カウント」は正しく設定されています (確認しました)。しかし、オーディオのストリーミングに新たな問題が発生しているようです。おそらく処理速度が十分ではありません。私には意味がありません。明らかに、バッファ コードは JVM コードの 3 つ以上のステートメントにコンパイルされますが、これを開始したとき、2 番目のバージョンは 1 番目よりも高速であるという合理的な仮定のように思えました。
明らかに、私は自分のコードが Java NIO バッファを使用しなければならないと主張しているわけではありませんが、少なくとも一見したところ、これを実行するのは「ベタ」のように思えます。
高速でシンプルな Java UDP リーダーの推奨事項と、一般的に受け入れられている「最善の方法」があるかどうかを誰かが知りましたか??
ありがとう、R.
java - Androidのダウンロードファイルのメモリ不足
起動時に22MB未満のzipファイルをダウンロードしようとしています。これらの例外の後でデフォルトのBufferedInputStreamを変更しましたが、それでもメモリ不足エラーが発生します。
スタック:
編集:わかりました。この例を機能させることができましたが、適切な権限があっても、権限が拒否されましたというエラーが表示されます。