Hi James, David, I've run our tests with the latest Grails 7.0.0-SNAPSHOT as James suggested and things seem to have improved a lot. Still a tiny bit slowish, but I would say that now the results are comparable, also with INDY ON.
That is great, thank you David, I feel better now :) Here they are: (Page 1 and Page 2 are different pages than those used in early tests so the absolute value is different than earlier) Grails 6/Groovy 3 Table -> TRANSITION rendered in 1319ms, args: [content:ContentTable View: /dueuno/elements/core/PageContent] Table -> TRANSITION rendered in 1475ms, args: [content:ContentTable View: /dueuno/elements/core/PageContent] Table -> TRANSITION rendered in 1315ms, args: [content:ContentTable View: /dueuno/elements/core/PageContent] Table -> TRANSITION rendered in 1322ms, args: [content:ContentTable View: /dueuno/elements/core/PageContent] Page 1 -> TRANSITION rendered in 20ms, args: [content:ContentTable View: /dueuno/elements/core/PageContent] Page 2 -> TRANSITION rendered in 31ms, args: [content:ContentTable View: /dueuno/elements/core/PageContent] Grails 7/Groovy 4 - INDY OFF Table -> TRANSITION rendered in 1414ms, args: [content:ContentTable View: /dueuno/elements/core/PageContent] Table -> TRANSITION rendered in 1384ms, args: [content:ContentTable View: /dueuno/elements/core/PageContent] Table -> TRANSITION rendered in 1439ms, args: [content:ContentTable View: /dueuno/elements/core/PageContent] Table -> TRANSITION rendered in 1416ms, args: [content:ContentTable View: /dueuno/elements/core/PageContent] Page 1 -> TRANSITION rendered in 26ms, args: [content:ContentTable View: /dueuno/elements/core/PageContent] Page 2 -> TRANSITION rendered in 55ms, args: [content:ContentTable View: /dueuno/elements/core/PageContent] Grails 7/Groovy 4 - INDY ON Table -> TRANSITION rendered in 1444ms, args: [content:ContentTable View: /dueuno/elements/core/PageContent] Table -> TRANSITION rendered in 1414ms, args: [content:ContentTable View: /dueuno/elements/core/PageContent] Table -> TRANSITION rendered in 1555ms, args: [content:ContentTable View: /dueuno/elements/core/PageContent] Table -> TRANSITION rendered in 1559ms, args: [content:ContentTable View: /dueuno/elements/core/PageContent] Page 1 -> TRANSITION rendered in 25ms, args: [content:ContentTable View: /dueuno/elements/core/PageContent] Page 2 -> TRANSITION rendered in 59ms, args: [content:ContentTable View: /dueuno/elements/core/PageContent] -- https://dueuno.com On Wed, 24 Sept 2025 at 15:16, Gianluca Sartori <[email protected]> wrote: > As suggested, we tested building a JAR. The results are good enough for us > to consider them production quality, although performance is still almost > twice as slow on common use cases (small pages with few objects to render). > Groovy INDY is set to OFF. > > > Grails 6/Groovy 3 > ================= > > Stress Test: > TRANSITION rendered in 1564ms > TRANSITION rendered in 1292ms > TRANSITION rendered in 1249ms > TRANSITION rendered in 1288ms > > Page 1: > TRANSITION rendered in 32ms > > Page 2: > TRANSITION rendered in 43ms > > > Grails 7/Groovy 4 > ================= > > Stress Test: > TRANSITION rendered in 1607ms > TRANSITION rendered in 1422ms > TRANSITION rendered in 1444ms > TRANSITION rendered in 1470ms > > Page 1: > TRANSITION rendered in 64ms > > Page 2: > TRANSITION rendered in 73ms > > > > Gianluca Sartori > -- > https://dueuno.com > > > On Mon, 22 Sept 2025 at 15:03, James Daugherty via dev < > [email protected]> wrote: > >> Hi Gianluca, >> >> When you say debug mode, you are doing all of your performance testing >> with >> debug mode? I would highly encourage you to test with runWar or runJar >> without debug mode. Debug mode has historically always been significantly >> slower. >> >> -James >> >> On Mon, Sep 22, 2025 at 4:30 AM Gianluca Sartori <[email protected]> >> wrote: >> >> > Hi David, >> > >> > Thank you for your reply, we've done the tests on the same code, the >> > "only" difference is Grails 6 VS Grails 7. Tests are not in >> > production, but locally from the IDE in debug mode. Yet grails 6 VS >> > Grails 7 tests share the same environment. >> > >> > We have a hierarchy of objects to build any view, those objects go >> > from a simple container to a Table that has a Body, a set of Rows, >> > each row has many Cells each cell can have a Label or many other >> > components. >> > >> > This hierarchy is rendered with GSP fragments (templates) so yes we >> > may have a lot going on under a rendered Table. I know that most of >> > the time is taken by the "layout engine" (?) because we've optimized >> > the Table rendering just by limiting the number of components, thus >> > embedding them instead of including them as separate templates. >> > >> > On the slowness, it is consistently slow but the warmup I've done was >> > a couple of browser refreshes by hand just to compile the GSPs, I >> > didn't go through a loop of 10.000 requests. >> > >> > About dynamically compiling GSP in production, we haven't specified >> > anything in the standard 'application.yml' config, but my senses feel >> > that even in production the first rendering takes longer I've always >> > thought it was because of GSP compilation and it is not a problem to >> > us. >> > >> > >> > Gianluca Sartori >> > -- >> > https://dueuno.com >> > >> > On Sun, 21 Sept 2025 at 17:18, David Estes <[email protected]> >> wrote: >> > > >> > > A bit surprising . Is it consistently slower or just the first few >> > times? Once it warms up it should still be ok for production no? Or are >> > you dynamically compiling gsp in prod? >> > > >> > > I agree it should be further optimized , but dismissing it for initial >> > performance seems aggressive. Unless it’s consistently significant on >> > slowness . >> > > >> > > That being said those render times in general seem very high for most >> > GSP I even render . Is there a large amount of taglib usage, layouts, >> etc? >> > Narrowing down what might be causing overall slow page renders may be >> worth >> > a gander. With those times I doubt it’s strictly GSP. >> > > >> > > >> > > > On Sep 21, 2025, at 9:26 AM, Gianluca Sartori <[email protected]> >> > wrote: >> > > > >> > > > I guess we need to find a solution refactoring GSP, rendering of >> > pages must >> > > > be as fast as possible. >> > > > >> > > > I will try to find time to give it a look but this means Grails 7 is >> > out of >> > > > scope for us at the moment. >> > > > >> > > > Unless we can run it with Groovy 3, i don’t like this, but if it >> > solves the >> > > > issue it would make it for us, do you think that would be possible? >> > > > >> > > > Should we switch to another templare solution? Which one would you >> > suggest? >> > > > >> > > > Cheers, >> > > > >> > > > Gianluca Sartori >> > > > -- >> > > > https://dueuno.com >> > > > >> > > > >> > > > ---------- Forwarded message --------- >> > > > From: Daniel Sun <[email protected]> >> > > > Date: Sat, 20 Sep 2025 at 01:46 >> > > > Subject: Re: GSP generation, Groovy 4 slower than Groovy 3? >> > > > To: <[email protected]> >> > > > >> > > > >> > > > Hi Gianluca, >> > > > >> > > > Groovy 4 enables indy by default. It's slower to run for the first >> > time >> > > > because the initialization for invokedynamic is quite expensive. ( >> See >> > > > also: https://bugs.openjdk.org/browse/JDK-8278540 ) >> > > > >> > > > It ususally gains best performance when the methods are invoked >> for >> > > > 10000+ times. >> > > > >> > > > BTW, Jochen proposed some optimization for current design of indy, >> > the >> > > > performance for the first runs will be much better when the >> > optimization is >> > > > done. >> > > > >> > > > Cheers, >> > > > Daniel Sun >> > > > >> > > >> On 2025/09/16 12:18:41 Gianluca Sartori wrote: >> > > >> Hi folks, >> > > >> >> > > >> we have started porting Dueuno to Grails 7/Groovy 4. We have a >> > > >> stress-test that generates a big table (200 columns x 100 rows) >> with >> > > >> GSP (we are doing server-side rendering). >> > > >> >> > > >> I'm reporting the tests below. Is there something we can do to get >> > > >> back the performances we had with Grails 6/Groovy 3? >> > > >> >> > > >> Even with INDY turned off we are almost 1sec slower on the tests, >> more >> > > >> than 2x slower on normal pages: >> > > >> >> > > >> Grails 7/Groovy 4 >> > > >> Page 1 - TRANSITION rendered in 185ms >> > > >> Page 2 - TRANSITION rendered in 453ms >> > > >> >> > > >> Grails 6/Groovy 3 >> > > >> Page 1 - TRANSITION rendered in 83ms >> > > >> Page 2 - TRANSITION rendered in 280ms >> > > >> >> > > >> TESTS >> > > >> ====== >> > > >> Same URL (Table stress-test), 4 requests after 3 warmup requests >> (not >> > > >> shown, cold-running the app from intelliJ), measuring the Grails >> > > >> render() execution time. >> > > >> >> > > >> From slower to faster: >> > > >> >> > > >> Grails 7 - Indy ON >> > > >> TRANSITION rendered in 4807ms >> > > >> TRANSITION rendered in 4779ms >> > > >> TRANSITION rendered in 4660ms >> > > >> TRANSITION rendered in 4699ms >> > > >> >> > > >> Grails 7 - Indy OFF >> > > >> tasks.withType(GroovyCompile) { >> > > >> groovyOptions.optimizationOptions.indy = false >> > > >> } >> > > >> TRANSITION rendered in 3660ms >> > > >> TRANSITION rendered in 3442ms >> > > >> TRANSITION rendered in 3510ms >> > > >> TRANSITION rendered in 3700ms >> > > >> >> > > >> Grails 6 >> > > >> TRANSITION rendered in 2853ms >> > > >> TRANSITION rendered in 2864ms >> > > >> TRANSITION rendered in 2734ms >> > > >> TRANSITION rendered in 2800ms >> > > >> >> > > >> Gianluca Sartori >> > > >> -- >> > > >> https://dueuno.com >> > > >> >> > >> >
