Here is the corraberating benchmark I saw recently: http://microbenchmarks.appspot.com/run/[email protected]/com.publicobject.blog.TreeListBenchmark described here: http://blog.publicobject.com/2010/07/caliper-confirms-reality-linkedlist-vs.html However looking at the code, I'm not totally thrilled with this as an apples-to-apples comparison. If you are interested, I can find and attach my own code which for Arrayist, LinkedList, and ArrayDeque did exactly the samething...fill it up and then simply iterated through it from beginning to end in the same manner. I think I timed the iteration seperately from the filling.
For some background, this was testing I did a year or so back for an application which had the ability to let the user perfrom an arbitrarily complicated search (defined in terms of domain entities) which could translate to pretty complex sql (lots of joins) and could occasionally return very large results. The way it was implemented at the time was rather simple and needed working over and I wanted to make it as scalable as possible. The first improvement was to page the results in the UI. Limit and offset proved not to be as useful as one would think. The only thing they save you is the network traffic time of the db sending you all the results; as with a count query, the db still has to do all the work of figuring out the results that it has to do if you ask for the full result set. To minimze the that transfer time I asked only for ids and performed another query later to get other information based on those ids for filling out a single page of results at a time. The set of ids I persisted in memory across pages (disposed after a certain amount of time) and since many users could potentially be using this at once I needed it to take as little memory as possible. I ended up using trove instead of the java collections so I could store a very compact list of primitives, but the testing I did converted me from using ArrayList as my "default" collection (as it is for most people, I think) to ArrayDeque, unless I really need random access. Sorry to be long-winded, but I thought that use-case might be of interest in thinking about scalability with jooq. Eric
