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 > >>
