[ 
https://issues.apache.org/jira/browse/LUCENE-9861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306599#comment-17306599
 ] 

Dawid Weiss commented on LUCENE-9861:
-------------------------------------

I've refactored this into a somewhat more shared logic (see the PR).

> speed up precommit
> ------------------
>
>                 Key: LUCENE-9861
>                 URL: https://issues.apache.org/jira/browse/LUCENE-9861
>             Project: Lucene - Core
>          Issue Type: Task
>            Reporter: Robert Muir
>            Priority: Major
>         Attachments: LUCENE-9861_hack.patch
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> A lot of the java tools for precommit aren't being called in efficient ways 
> (compilation, linting, etc).
> For example ecjlint, it runs very slow:
> {noformat}
> Aggregate task times (possibly running in parallel!):
>  271.73 sec.  ecjLintMain
>  270.18 sec.  ecjLintTest
>  227.17 sec.  compileJava
>   12.07 sec.  compileTestJava
>    1.21 sec.  processResources
>    0.18 sec.  clean
> {noformat}
> Simplying adding a couple reasonable jvm arguments to the ecj linter 
> ({{jvmArgs = [ '-XX:+UseParallelGC', '-XX:TieredStopAtLevel=1' ]}}) speeds it 
> up significantly.
> Speedup for ecjLint is 3x for me:
> {noformat}
> Aggregate task times (possibly running in parallel!):
>  163.38 sec.  compileJava
>   84.57 sec.  ecjLintMain
>   83.12 sec.  ecjLintTest
>    6.11 sec.  compileTestJava
>    0.95 sec.  processResources
>    0.15 sec.  clean
> {noformat}
> I imagine same may be true for a lot of these tasks. We're currently tossing 
> default jvm args at these short-lived subprocesses, which is very suboptimal.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to