On Fri, Apr 11, 2025 at 8:11 AM Engebretson, John <jeng...@amazon.com> wrote:
> It seems like a good general-purpose list but I wouldn’t recommend it as a > direct replacement for either ArrayList or LinkedList; in the former case > the risk is slower random accesses, and in the latter the risk is to head > modifications. > Interesting results. However I don't think comparing this to both ArrayList and LinkedList is really fair. Developers choose an implementation based on how they know they are going to use it: If they are just adding stuff, they choose ArrayList. If they know they need to insert/remove in the middle, they choose LinkedList. If they need to add/remove from both ends, they choose ArrayDeque. Etc. So the optimal design changes depending on which "flavor" of list usage the developer is implying when they choose some implementation class. E.g., if you wanted to target the "ArrayList flavor', then you'd use fixed size, power-of-two segments. Then get() remains constant time, and insert and remove remain as painfully slow as ever, but the common "list builder" usage pattern of "append, append, append, ..., use read-only thereafter" gets a lot faster. OTOH variable-sized chunks makes lots of sense for the "LinkedList" flavor. In fact you could have a LinkedList<T> that just uses an ArrayList<ArrayDeque<T>> internally :) -Archie -- Archie L. Cobbs
