On 22/06/2007, at 11:10 PM, Michael Gentry wrote:
Marcin, this thread might be of interest to you ...http://mail-archives.apache.org/mod_mbox/cayenne-dev/200705.mbox/ browserLook at the "Paging and SQL queries" thread on May 25.
Yes, this is the same project we are working on. I started some performance profiling and Marcin has been able now to take it much further. What is it about:
elements.add(it.nextObjectId(entity));
which is so slow? The code gets a little complex at that point and we are having difficulty tracing it through to the exact performance problem in the underlying code. Is it the speed of adding the object id to the Collection or the speed of creating an object id itself? 0.5ms doesn't sound slow, but it doesn't scale well.
Andrus, I got the impression from the previous thread that you suspected something slightly different. That the performance problem might be in the fat query itself, but from our tests this isn't the case. If I've got this right, the way it works is:
1. perform regular query to get all columns but return result in iterator
2. iterate through first page and build full objects3. iterate through other pages and build just objectids (this is the slow part for us) 4. when another page is fetched perform another query and fetch those objects from the DB
So, getting just primary keys from the DB may not be any faster if the performance problem is simply in the construction of objectIds. If the performance problem is in the numerous resizings of the Collection (each time it runs out of space, then it is increased by 50% or 100% in size), then the solution could be as simple as figuring out the size of the iterator and sizing the collection appropriately from the beginning.
Any ideas on how to discover the exact cause of the performance hit? Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
PGP.sig
Description: This is a digitally signed message part
