I upgraded my local stack to lucee 6.2.2 / jdk 21 / tomcat 11.
I have a small script, uploading a csv file (6 columns), parse each data field (e.g. validate) and then i collect the rows in an array. If the array length is 100, I create one “INSERT INTO” sql statement with 100 rows.
The file has 363 rows, really nothing special and this works within less seconds.
After the upgrade, the script ran in a timeout and the Query each-function is terrible slow:
Here’s a small test case that reproduces the bug.
To get it running, create the test table (first comment) and change the datasource (line 14). I hope this helps.
Thank you very much for your reply. Is there a chance you will merge the logic in the backend or do I have to rewrite the code? We have currently 888 “new Query” in the code…
Are there any other deprecated functions I should know about? I just know this page: Deprecated Tags & Functions :: Lucee Documentation
We will be addressing that perf regression, but it will never be as fast as plain old cfquery, especially when working with queries with a lot params, so refactoring is defiantly going to potentially bring performance benefits, depending on your usage
Adobe did deprecate all the new Query() stuff we haven’t as of yet, it’s just slower, but some people prefer the more expressive approach
As for other things, nothing springs to mind, using stringbuilder like that, especially with newer versions of java, might not be worth the effort, but that’s something to benchmark yourself
6.2.2.72-SNAPSHOT has the additional performance tweak
with a test case with 500 params, it now takes 232ms, rather than 345ms
The latest Lucee snapshots aren’t currently available via the admin due to some maven problems, you can just drop this into /deploy to test https://cdn.lucee.org/6.2.2.72-SNAPSHOT.lco
Ah, I see. Well, glad to see that QueryExecute() has near-identical performance because cfscript is so much easier to read, especially when the <cfquery> has tons of ugly <cfqueryparam> tags, which every secure query should, of course.
Also, the QueryExecute() code example in that doc page is more verbose than it needs to be, and oddly uses positional parameter binding instead of named parameters which are much easier to read.