Comments (5)
Noting that Gretty 2.x still claims in docs to support Gradle 1.10 !!, although surely hardly anyone relies on that (nor should they) and we certainly don't test it. I understand @CompileStatic
would require Groovy 2.x making Gradle 2.x minimum. So it's another one to add to the support-matrix deprecation list for the next-release, and depending on the branch/version we might deprecate Gradle 2.x support too.
from gretty.
Hoping that @wolfs or @rwinch can validate an initial/basic approach for this, and the results, or anyone else with @CompileStatic
or Gradle/Groovy performance-tuning experience.
Here's what I tried:
Baseline data:
- There's 324
*.groovy
files in the project, including a handful of atypical source files for build etc. - Full integration-test for a specific test-config ranges from 10m42s to 17m15s for a range of containers.
Approach
- Add a
config.groovy
containingast(groovy.transform.CompileStatic)
and reference it. - For each location using dynamic Groovy, or other code which causes a static-compilation Java check to fail, just annotate the entire class with
@CompileStatic(TypeCheckingMode.SKIP)
. No attempt to limit this to specific methods at this point. - The above results in 60 classes that are skipped and not statically-compiled, retaining dynamic Groovy.
- Make other minor fixes e.g. adding required casts to fix remaining static-compilation errors.
Results
Completely unscientific, anecdotal from a single run.
- Jetty 7 test failed with a
java.lang.IllegalAccessError
. Not a huge concern as Jetty 7 support is scheduled for deprecation. Another container failed but with a known fragile-test issue and passed on re-run. - Test execution times (single run, these times are also sometimes a blend of containers and not all containers run all tests):
Container | Dynamic Compilation | Selective Static Compilation | Change |
---|---|---|---|
jetty7 | 10m42s | failed | X |
jetty8 | 15m40s | 15m12s | -22s |
jetty9.2 | 14m51s | 13m15s | -1m36s |
tomcat7 | 13m17 | 13m30s | +13s |
tomcat8 | 17m15s | 12m16s | -4m59s |
tomcat8.5 | 12m30s | 11m56s | -34s |
tomcat9 | 13m21s | 12m49s | -32s |
Comment
Seems like an overall improvement, but apart from one dynamic change, nothing spectacular.
Questions
- Is the above approach reasonable, or how could it be improved?
- Any way of further validating what has been done?
- Any point in doing hotspot analysis to try and apply more static-compilation by being more selective with exclusion using method-annotations, or "fixing" bits of code so they work statically?
from gretty.
@javabrett Thank you for trying it out!
Regarding your numbers above: I don't understand why these improvements would be caused by adding CompileStatic
: CompileStatic
will only improve the execution time of scripts, since less dynamic invocations need to be done, which may be expensive.
So the improvement would be in configuration time of the build. I guess all the above projects are small, right? So you wouldn't even notice configuration time improvements. Did you restart the daemon between runs? If not, then the time improvement is due to having a warm daemon.
If you want to do some performance measurements, please use gradle-profiler. That would allow you to get more accurate measurements.
Moreover, for testing the configuration time improvements, you would need a sufficiently big project (maybe 100 sub-projects), each applying the Jetty plugin.
Note that it is not necessary to convert all classes to CompileStatic
, only the ones which are executed when the plugin is applied (as opposed to when the plugin's tasks are executed) would be enough.
from gretty.
Thanks @wolfs for the comments and help.
Note that it is not necessary to convert all classes to CompileStatic
I think that was my reaction to the issue summary "Convert most classes to use @CompileStatic" and "Using CompileStatic on a significant number if not on all classes" :).
... only the ones which are executed when the plugin is applied (as opposed to when the plugin's tasks are executed) would be enough.
So that might be in GrettyPlugin#apply
and everything called from there? Note that this had compile-errors when compiled Java static, so it was excluded for the first-pass approach.
There's also https://github.com/gretty-gradle-plugin/gretty/blob/master/integrationTests/buildSrc/gretty-integrationTest/src/main/groovy/org/akhikhl/gretty/internal/integrationTests/BasePlugin.groovy#L109 for dev.
So the improvement would be in configuration time of the build.
I think this refers to a Gradle build of a project which applies the Gretty project once or more (rather than the build of the Gretty project itself).
Regarding your numbers above: I don't understand why these improvements would be caused by adding CompileStatic: CompileStatic will only improve the execution time of scripts, since less dynamic invocations need to be done, which may be expensive. So the improvement would be in configuration time of the build. I guess all the above projects are small, right? So you wouldn't even notice configuration time improvements. Did you restart the daemon between runs? If not, then the time improvement is due to having a warm daemon.
The timing numbers refer to builds which run integrationTests
, which run on Travis, where I believe the Gradle Daemon is disabled by-default, or at least each build runs in a clean Docker. Per above at least one important class has been disabled. Probably any reduction is coindidental.
Moreover, for testing the configuration time improvements, you would need a sufficiently big project (maybe 100 sub-projects), each applying the Jetty plugin.
I was tempted to ask what a canonical test for performance-improvements might look like before I started - sounds like this is it.
from gretty.
The configuration-time performance improvement from adding @CompileStatic
should now be available in Gretty 2.3.0-SNAPSHOT
and 3.0.0-SNAPSHOT
. A 2.3.0 release shouldn't be too far away.
A subsequent buildscan
for spring-security
is available at https://scans.gradle.com/s/o6jlskwqa7k3y .
Thanks @rwinch for the report and @wolfs and @oehme for the profiler support.
from gretty.
Related Issues (20)
- Not able to run the app using Gretty 4.0.3 in combination with JDK17 and Gradle 7.5.1. HOT 2
- Wrong warning about missing slf4j provider HOT 1
- Gretty 3.0.8+ is incompatible with Proguard `7.3.0` HOT 4
- Cannot inject Tomcat DBCP 2 library in Gretty 3.1.0 via dependencies/gretty HOT 4
- Gretty always configures the `war` task
- Some logger properties missing when upgrading from 3.0.6 to 3.1.1 HOT 6
- Update Documentation on Gretty Logging
- No such property: CONTAINER_JAR_PATTERN for class: org.eclipse.jetty.webapp.MetaInfConfiguration HOT 4
- Gradle 8 deprecation warnings
- Exception occurs when using Gretty and Thymeleaf Layout Dialect together. HOT 1
- 4.0.3 -> 4.1.0 HOT 1
- Errors seem to leave gretty/jetty running without the ability to shutdown without killing processes manually HOT 3
- Upgrading to 4.0.1 and now getting CONTAINER_JAR_PATTERN error HOT 1
- JettyRestart task fails with MissingMethodException: No signature of method: org.akhikhl.gretty.JettyServerManager.startServer HOT 6
- ExtraResourceBase not found after updating from 3.x to 4.x
- Remove usage of deprecated `org.gradle.util.VersionNumber` HOT 1
- Gretty 4.1.1 requires the `src/main/webapp` path.
- jettyStart throws exception if using jetty-env.xml
- Crash when trying to run a product built with buildProduct HOT 3
- CVE-2024-30172 in bouncycastle 1.77
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gretty.