jonnybot0 commented on PR #306: URL: https://github.com/apache/groovy-geb/pull/306#issuecomment-4226235343
@matrei - I do think considering performance more deeply is a good idea. I'd also agree that `@CompileStatic` can have a big impact on that, and it may be worth doing some deep comparisons with Groovy 5 & 6 with & without this `@CompileStatic` thing. It doesn't appear to have made a difference for the Grails suite, but I'm not sure I would say "scrap it" right away. Still, to merge anything on performance grounds, we'd need some kind of demonstration of the performance benefits. Spock has had a Groovy 5 supporting release since December, so it should be pretty doable to work up a version of Geb that can run on Groovy 5. I wouldn't expect to see any performance gains until Groovy 6 (currently in alpha), but again, you never know until you measure. :) That said, I recognize you're volunteering the project & I want to be respectful of your time. If you're keen to have a go at performance, here are things I can think of that might be useful: 1. Do some performance profiles in reproducible infrastructure, like GitHub Actions. The Java Flight Recorder would probably be the best choice for that. If you could find some "hot paths" or obvious memory leaks, we could try and address those directly, using the profiler to verify them. 1. Do some kind of benchmarking or load testing. I'm a little less certain what the best choice would be, though. I've used [jmh](https://github.com/openjdk/jmh/tree/master/jmh-samples) before, and know that Cedric Champeau made [a nice Gradle plugin for it](https://github.com/melix/jmh-gradle-plugin) which should make it reasonably easy to use. At the same time, Browser testing is such a high level thing that I'm not confident micro-benchmarking is the right fit. Maybe [gatling](https://github.com/gatling/gatling) would be better? The main idea would be something that could exercise the code really heavily & repeatedly to see if there were changes over a large number of iterations. Those are both fairly deep dives, though. If you weren't up for that, no worries! We can close this and keep it as a record for someone who wants to chase that down on some future date. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
