⚡️ Speed up function _get_strategy by 28% in PR #1774 (feat/gradle-executor-from-java) - #1800
codeflash-ai[bot] wants to merge 17 commits into
Conversation
Add full Gradle executor support alongside existing Maven support using init scripts to inject configuration without modifying project build files. Key additions in build_tools.py: - Gradle project info extraction (group, version, java_version) - Classpath extraction via init script with printCfClasspath task - Gradle compilation (gradlew testClasses) - Gradle test execution (gradlew test --tests) - Runtime JAR installation to ~/.m2 (no Maven needed) - Multi-module detection from settings.gradle(.kts) - JaCoCo coverage support via init script Key additions in test_runner.py: - Build tool dispatch in run_behavioral_tests, run_benchmarking_tests, and run_line_profile_tests - Gradle-specific compile, classpath, and test execution functions - Direct JVM fallback pattern (compile-once-run-many) for Gradle - Generalized multi-module root detection for both Maven and Gradle Key additions in config.py: - Gradle compiler settings detection (source/target compatibility) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Use `gradle.rootProject.allprojects` and `gradle.allprojects` in init scripts instead of bare `allprojects` which is not available on the Gradle object - Reorder jacoco task after --tests filters so Gradle scopes them only to the test task, fixing "Unknown command-line option '--tests'" error Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…ation When AI-generated test files have compilation errors (e.g., bad imports like `import org.openrewrite.ipc.http.of`), they poison the entire module's `compileTestJava`. This adds a retry: if compilation fails, delete any codeflash-generated test files (matching __perfinstrumented patterns) and retry, so subsequent functions aren't blocked. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Avoid ZeroDivisionError when candidate behavioral tests return no results and the repair path tries to compute unmatched percentage. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
resolve_test_file_from_class_path only looked for pom.xml when walking up to find the project root, so Gradle-only projects never matched and the src/test/java lookup was skipped entirely, causing TestResults=0. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…files _run_gradle_tests and _run_gradle_tests_coverage run `gradle test` which compiles ALL test files in the module. When a previous function's AI-generated test has compilation errors (undefined variables, bad imports), it poisons compileTestJava for the entire module, causing TestResults=0 for all subsequent functions. The retry-after-delete logic already existed in _compile_tests_gradle (used by the direct JVM path) but was missing from the full Gradle test and coverage paths. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…g current tests Two bugs causing TestResults=0 for Gradle Java projects: 1. SQLite result parsing (parse_test_output.py): Java uses "json" format like Jest, so test_module_path (a Java class name) was resolved using Jest's file-path logic, producing wrong paths like `src/test/java/MyTest__perfinstrumented` instead of the actual `src/test/java/com/example/MyTest__perfinstrumented.java`. This caused all test_type lookups to fail, losing XML pass/fail merge data. 2. Broken file deletion (test_runner.py): _delete_broken_generated_test_files with sweep_all=True deleted ALL generated test files in the module, including the current function's tests. When _run_gradle_tests retried with the same --tests filter, it got "No tests found" because the needed files were gone. Now uses sweep_all=False for callers that retry with a --tests filter. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Gradle swallows test process stdout by default. CodeflashHelper prints timing markers to stdout, but they never reached the Gradle process output, causing all benchmark runtimes to be 0. Adding showStandardStreams=true to the test task config forwards stdout so timing markers are captured. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
run_line_profile_tests accepted javaagent_arg but never passed it to the JVM when using the Gradle execution path. Thread the arg through _run_direct_or_fallback_gradle -> _run_tests_direct where it is prepended to the java command line. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…va tests When AI-generated tests call the target function indirectly (e.g., via reflection, ClassValue.get(), wrapper methods), the timing instrumentation couldn't find direct calls and returned the test body unchanged — no timing markers were emitted, causing benchmark runtime to be 0 and baseline failure. Now wraps the entire test body in a timing block as a fallback when no direct target calls are found. Only applies to generated tests (not existing tests) and skips @disabled methods. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The optimization replaces chained `/` operators (which create multiple intermediate `Path` objects) with a single `joinpath()` call that combines all path segments at once. Line profiler data shows the hot-path return statements dropped from ~28.6 µs/hit to ~14.1 µs/hit (with module) and ~21.2 µs/hit to ~11.9 µs/hit (without module), confirming that consolidating path operations reduces per-call overhead. This yields a 112% runtime speedup (18.0 ms → 8.47 ms) across 4640 invocations in the profiler, with no functional regressions in any test case.
…2026-03-07T00.07.24 ⚡️ Speed up function `get_gradle_test_reports_dir` by 112% in PR #1774 (`feat/gradle-executor-from-java`)
… and extract build tool strategy - Guard single-block code replacement against filename mismatches to prevent duplicate method compilation errors (e.g. ReflectionUtils → StringUtils) - Fix loop index parsing to use regex instead of fragile string splitting - Access XML message attribute safely via _elem.get() instead of .message - Extract BuildToolStrategy ABC with Maven/Gradle implementations in test_runner Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The optimization replaces on-demand `MavenStrategy()` and `GradleStrategy()` instantiations with module-level singleton instances `_MAVEN_STRATEGY` and `_GRADLE_STRATEGY`, eliminating repeated object allocations in the hot `_get_strategy` function. Line profiler confirms the return statements dropped from ~214–223 ns/hit to ~116–125 ns/hit (≈45% per-hit improvement), and the function is invoked 8,537 times across multiple call sites (`run_behavioral_tests`, `run_benchmarking_tests`, `run_line_profile_tests`). Because both strategy classes are stateless (they delegate all work to module-level functions), reusing instances preserves correctness while cutting total runtime by 27%.
|
Claude finished @codeflash-ai[bot]'s task in 2m 49s —— View job PR Review Summary
Prek Checks
Code ReviewThe optimization is correct and safe. Both One observation: the generated regression tests shown in the PR body include assertions like Singleton placement at module bottom (after both classes are defined) is correct. Duplicate DetectionNo duplicates detected. The strategy pattern here is specific to the Java language module; the Python and JavaScript modules have no equivalent Test CoverageThe changed lines are in Optimization PRs
| Branch |
41a4e02 to
f4a4ac6
Compare
|
Ubuntu seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
|
Closing stale optimization PR — merge conflicts with target branch. |
⚡️ This pull request contains optimizations for PR #1774
If you approve this dependent PR, these changes will be merged into the original PR branch
feat/gradle-executor-from-java.📄 28% (0.28x) speedup for
_get_strategyincodeflash/languages/java/test_runner.py⏱️ Runtime :
2.58 milliseconds→2.02 milliseconds(best of150runs)📝 Explanation and details
The optimization replaces on-demand
MavenStrategy()andGradleStrategy()instantiations with module-level singleton instances_MAVEN_STRATEGYand_GRADLE_STRATEGY, eliminating repeated object allocations in the hot_get_strategyfunction. Line profiler confirms the return statements dropped from ~214–223 ns/hit to ~116–125 ns/hit (≈45% per-hit improvement), and the function is invoked 8,537 times across multiple call sites (run_behavioral_tests,run_benchmarking_tests,run_line_profile_tests). Because both strategy classes are stateless (they delegate all work to module-level functions), reusing instances preserves correctness while cutting total runtime by 27%.✅ Correctness verification report:
🌀 Click to see Generated Regression Tests
To edit these changes
git checkout codeflash/optimize-pr1774-2026-03-09T21.29.32and push.