一部の Java フレームワークで使用される実装スタイルについて質問/懸念があります。
まず、一般的な背景として、オブジェクトの配列を作成することは、生の/プリミティブな配列タイプを作成するよりもはるかにコストがかかることを実践から知っています。たとえば、下のレイヤーに大量の文字データを要求する場合、最も効率的な選択は、ラッパー データ型を発明してオブジェクトの配列を返すのではなく、char[]、byte[]、ByteArray などの型を使用することです。
ただし、独自のデータ型を実装しているように見えるフレームワークを見てきましたが、それらの型の配列がやり取りされることを期待しています。これにより、前述のパフォーマンスとコストの問題がすべて発生し、変換コードのオーバーヘッドが発生するため、非常に不便です。
たとえば、sblim クライアントの javax.cim パッケージで定義されている型を考えてみます。
http://sblim.sourceforge.net/cim-client2-v22-doc/javax/cim/package-summary.html
基本的にバイトである UnsignedInteger8 という名前の型が 1 つあります。同等の効率的なプリミティブ型を持つ他の型もあります。プロトコルに準拠するためにJavaクラスで異なるデータ型をカプセル化しているように見えるDMTFデータ型についてのコメントがありますが、どのコストがかかりますか?
要するに、Java のパフォーマンスとフレームワークの設計全般に詳しい人が、sblim クライアントが効率的な実装であるかどうかについてフィードバックを提供できるかどうかを知りたいのです。UnsignedInteger8 のようなこのラッパー型を単にバイトまたは文字を使用できた場合に使用する根拠または正当化はありますか? すべての DMTF データ型を処理するための標準化された統一されたコードを作成することは、プリミティブ型の代わりにオブジェクトの配列を使用することを意味するパフォーマンスの欠如を正当化しますか? ここで私は要点を正しく理解していますか、それとも間違っていますか?
前もって感謝します！
アップデート
私の主張をさらに示すために、次の抜粋を検討してください。
static StringBuilder convertToText (UnsignedInteger8[] u8arr) {
if (u8arr== null) return null;
StringBuilder sb = new StringBuilder(u8arr.length);
for (UnsignedInteger8 u8 : u8arr) {
sb.append((char)u8.shortValue());
}
return sb;
}
文字データのチャンクを StringBuilder にマップするには、そのようなコードを使用する必要があります。データはすでに CIM によってメモリ内にロードされているため、これは非常に非効率的です。新しい StringBuilder を作成し、すべてのデータを再度反復/コピーする必要があるのはなぜですか? CIM クライアントが String、byte[]、char[]、または ByteBuffer を提供できないのはなぜですか? これは非常に非効率的だと思います。なぜこの世界でこのように実装したのかを理解したいと思います。
データ型を抽象化し、Comparable、Equals、Collections API などの Java が提供する機能を使用する利点を理解しています。これは理にかなっており、Person、Account、Transaction などの複雑な構造化データには使用する価値があると思いますが、生/プリミティブ データ型には使用しないでください。それは多すぎる。