One of the really great features of CFML is the ability to run SQL against a result set in memory. This allows you to union separate results together or even apply additional filtering on an exiting result if you can’t control what the DB gives you. Like everything, there is a time and a place for this. There are people who strongly dislike QoQ (query of queries) but my take is that I think they’re great when used with relatively small data sets and unless performance profiling shows they are causing issues, I have no problems using them.
The Lucee developers however have often told people never to use QoQ because they were slow. Recently, I found out why. Ortus has a client moving a large application over from various versions of Adobe ColdFusion to Lucee Server. They have a lot of reports that grab a query from the DB and then chop it up inside loops using QoQ to crunch the data and generate the output. This has worked well for them in Adobe CF for years, but when testing their site in Lucee, the pages slowed to a crawl. And then more than one user hit their site at once, it got even worse! This client asked Ortus/me to take a look at help them figure out why Lucee was so slow.
Great read and awesome results! We recently had to pull out some uses of QoQ due to issues, and it would be awesome if we could trust it to perform well.
@bdw429s Just saw the test results in the PDF file you’ve submitted! OMG!!! I’ve always avoided QoQ before. Big thanks to you and to Ortus for this improving contribution.
I’m beginning to move more and more into QoQ to minimize the number of ODBC connections on a busy server. Thankfully most of these are small, and I haven’t noticed too much lag. That said, I’m adding a reporting feature which will do a lot of these per page, which could slow things down. Looking forward to these improvements.
