(ヒープおよびダイレクトバッファによるByteBufferの性能差、およびUnsafeとのパフォーマンスも比較するよ！) (とりあえず計測結果を先に知りたい人は結論を見てね！) (ファイルのシーケンシャルリードを含むダイレクトバッファの使い方やパフォーマンス比較については次の日記に書きました。) 概要 思うところあって、ヒープ上のbyte[]をラップしたByteBufferと、ダイレクトバッファを確保しているByteBufferの場合とのint型としての連続アクセスした場合のパフォーマンスの違いについて調べてみることにした。 私の認識では、ダイレクトバッファへのアクセスは非ネイティブ側(つまりJavaコード側)からのアクセスではオーバヘッドが大きいため、特殊なシチュエーション以外では遅くなってしまうため、あまり使いどころのない機能だというものだったのだが、では、その使いどころとなる「特殊な
OpenJDK や Hotspot VM には sun.misc.Unsafe という内部APIがあり*1、これを使うと ByteBuffer.getInt や ByteBuffer.getLong よりも高速にバイト列から整数値をデコードできるという。これを駆使することで、Cで実装された拡張ライブラリに匹敵する速度を出せるらしい。 それが本当なら、データ圧縮やハッシュ関数、シリアライザ/デシリアライザなどの実装を高速化できる。例えば、lz4 や xxhash のJava実装が Unsafe API を使用している*2：jpountz/lz4-java Prestoも、中間データのシリアライズ/デシリアライズにはすべて Unsafe API を使っている*3。 そこで、実際にベンチマークしてみた。 ベンチマーク内容 10MBのランダムなバイト列を生成する 先頭から1バイト読み出す その1バ
ネットワークで取り扱うデータ形式には、バイナリ形式のものが多く、さらにビット単位に割り付けられているものがあります。 例えば、時刻同期でおなじみのNTPでは、RFC2030で規定されているフォーマットがあります。 先頭部分を抜粋したのが次です。 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |LI | VN |Mode | Stratum | Poll | Precision | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root Delay | +-+-+-+-+-+-+-
Direct Memory Alignment in Java
Summary: First in a quick(hopefully) series of posts on memory alignment in Java. This post introduces memory alignment, shows how to get memory aligned blocks, and offers an experiment and some results concerning unaligned memory performance. Since the first days of Java, one of the things you normally didn't need to worry about was memory. This was a good thing for all involved who cared little
96 97 1D 59 33 7B 7E 25 03 BC C2 51 AC F6 1D 0F 62 DA 4D 88 09 DD 3B 58 6F D5 84 1F 99 20 3B B1 7B 40 B4 77 CB 8A E3 05 23 2A 72 7D 5E 19 1C ED 7D 8C 35 F4 7D F3 F5 E4 8E 50 4D 9A 35 C4 95 DE C1 82 42 0B 84 31 E9 AD FE 07 CF B5 EB AE E2 62 0D 3A C1 80 07 1E B5 77 3D 3C DE 95 1B 51 99 A5 BB C6 ByteBuffers and Off-Heap Memory 96 97 1D 59 33 7B 7E 25 03 BC C2 51 AC F6 1D 0F 62 DA 4D 88 09 DD 3B 58 6F
大規模ミッションクリティカル系システムのためのTips。 たった1分遅れただけで、満席になってて座れないぐらいの人気セッションでした。 内容的にも、知らなかったTipsが多い、得るものの多いセッションでした。 このセッションで対象にするシステムは、メモリが16〜100GBぐらい、 スレッドが10〜100ぐらい同時に動くような規模のもの。 1. Heapを抑えるために、Composed OOPS (COOPS) を使いなさい。 方法 : -XX:+UseCompressedOOPS 効果 : ヒープに長く残っている情報を圧縮する。実際2.76GB → 2.27GBになった。 2. 1スレッドで（1リクエストで）たくさんのオブジェクトを生成する場合は、NUMAを使いなさい 方法 : -XX:+UserNUMA 効果 : GCの効率が改善する 3. 共有メモリを良いパフォーマンスで読み出したいな
Native C/C++ Like Performance For Java Object Serialisation
Do you ever wish you could turn a Java object into a stream of bytes as fast as it can be done in a native language like C++? If you use standard Java Serialization you could be disappointed with the performance. Java Serialization was designed for a very different purpose than serialising objects as quickly and compactly as possible. Why do we need fast and compact serialisation? Many of our s
Byte Buffers and Non-Heap Memory Originally published: 2010-04-04 Last updated: 2017-01-22 Most Java programs spend their time working with objects on the JVM heap, using getter and setter methods to retrieve or change the data in those objects. A few programs, however, need to do something different. Perhaps they're exchanging data with a program written in C. Or they need to manage large chunks
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
