非常に熟練した低レイテンシのJava開発者（私はそうではない）で、int（プリミティブかどうか）を実装するように指示された場合、すべての新しいエントリが以前にそのセットに格納された他のどの値よりも高いことを保証された事前条件が与えられれば、余分なパフォーマンスが得られますか？整数の集合。新しいエントリを増やした場合のパフォーマンスの向上
最高/最悪のシナリオでは、add,containsおよびremoveの操作でどの程度の利益が得られるでしょうか？
一方で、このような制限がパフォーマンスを向上させることは当然のようです。一方、非減少エントリは、非常に一般的な状況（例えば一意のIDの生成）であり、利得が争う価値がある場合、多かれ少なかれ既知の実装が既に開発されているであろう。
これをチェックすると、addとcontainsは既にO（1）であることがわかります。だからそこに改善することはあまりありません。
そして、私はこれら二つは一度だけこの制約から利益を得ることができるだろうと思い：
にすることはできませんしかし、それはそれについてあるとき、瞬時にわかります最初の事前チェックを持っています。
そして、それを越えて：あなたの制約が追加されようとしているそれぞれの「新しい」エントリが最後の1より大きいことが本当にある - あなたは最初の場所で設定を必要としません。 の制約は、すべてのアイテムが一意であることを保証しているためです。そういう意味で、あなたもリストを調べることができました。
O（1）とO（1.5）の間にある可能性のあるデルタの間に質問がしているコメントについて。私の反応：
O（1）とO（n）の違いは理論的な性質のため、ペンと紙を使って答えます。 O（1.0）とO（1.005）の違いは... 実験とベンチマークで始まります。
意味：これらの「実際の」要素は、基本となる実装に「近い」さまざまな要素に依存します。まず、現在使用しているセットがのプラットフォームにどのように実装されているかを調べることから始めます。 上のJVMがあなたのプラットフォームでジャストインタイムコンパイルを実行している様子を示します。そこから、あなたはこの制約を考慮に入れて改善できるものについて結論を導くことができます。
最後に、制約については、は、既存の実装であるを劣化させます。私はこれもまた起こるかもしれないと思う。そのような詳細は本当に特定の実装に依存します。それを超えて：3つの異なる操作に名前を付けました。実際の結果は非常に異なる場合があります。操作の種類によって異なります。
この問題を解決する必要がある場合は、私は、 "テストデータ"（乱数、増分のみの数値、その変形）を使ってかなり大きなファイルを作成することから始めます。そしてプロファイラ（または少なくとも洗練されたbenchmarking）を使用して測定を開始します。
このような微妙な可能性のあるパフォーマンスについて質問し、ひっそりと「*（プリミティブかどうか）*」を捨てることは矛盾しているようです。パフォーマンスが*本当に*重大である場合、*プリミティブ*型だけを使用してください。いくつかのプリミティブコレクションライブラリがあります。 – Marco13
整数を追加すると、複雑さは0が2バイトに格納され、Integer.MAXも2バイトに格納されます。 – nafas
@ Marco13もちろん、プリミティブセットはより良く動作し、私は他の実装よりも優先しますが、質問はむしろ理論的なものです。 – Osw