[GitHub] groovy pull request #719: Optimize generation of Groovydoc

[melix <gi...@git.apache.org>]

GitHub user melix opened a pull request:

    https://github.com/apache/groovy/pull/719

    Optimize generation of Groovydoc

    There's a lot to say about Groovydoc, but worst of all, its performance is terrible. This PR is an attempt to fix part of it.
    
    Before my changes: https://scans.gradle.com/s/msfs2nf5mqmxw (3m35s)
    After my changes: https://scans.gradle.com/s/a7pi5g6bb7bbu (53s)
    
    @paulk-asert I'm leaving the review/merge to you as I spent already too much time on this. Given the improvements, I wouldn't mind a backport to 2.5!

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/melix/groovy cc/faster-groovydoc

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/groovy/pull/719.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #719
    
----
commit 3a8dd6d5b3f36e7058567f32264ce9c3126e3631
Author: Cedric Champeau <cc...@...>
Date:   2018-05-23T06:34:10Z

    Cache class resolution
    
    As soon as we have a project with a reasonable size, we spend a large
    amount of time resolving the same classes again and again. This commit
    introduces a (poor man's) cache to avoid the same lookups. It's not an
    attempt to make Groovydoc better, it's just a patch to make it not so
    slow.

commit d8f4ec430f1285c36375047b0f3488a313602555
Author: Cedric Champeau <cc...@...>
Date:   2018-05-23T06:35:41Z

    Use a reasonable size buffer for generated docs
    
    The default buffer is a 16(!) characters string. Most of the groovydoc
    files we generate are over 10k, so this commit adds a reasonable size
    buffer for templates, which avoids a lot of buffer resizes.

commit c5832093ff9992537db1856b7f0dae58e9fe0081
Author: Cedric Champeau <cc...@...>
Date:   2018-05-23T07:49:38Z

    Perform direct lookup in maps
    
    Why the h... we were iterating over the map to check each entry
    is beyond my understanding.

commit af7605f5ff84cb7a381696fb0d3da8c4902ff658
Author: Cedric Champeau <cc...@...>
Date:   2018-05-23T07:59:59Z

    Implement a bit smarter lookup
    
    The code isn't really clear what the inputs/outputs are, so it's
    just reordering things to make it faster.

commit f810c805922155988395ee1f996530987b0b71f6
Author: Cedric Champeau <cc...@...>
Date:   2018-05-23T09:03:47Z

    Optimize StringBuilder#leftShift for GString case

commit a5c49a01678fe13145c8e32b415f68361544d06b
Author: Cedric Champeau <cc...@...>
Date:   2018-05-23T09:42:42Z

    Don't use exception for control flow
    
    It's extremely slow, as we generate tons of stacktraces for nothing!

commit 12d375852d0c83b5e5924a12d09af6035496aaa2
Author: Cedric Champeau <cc...@...>
Date:   2018-05-23T09:58:11Z

    Cache classNamed lookups
    
    The calls to `substring` are pretty expensive and done again and again
    on the same classes. This is extremely inefficient, so this commit adds
    an adhoc cache for this. Note that the relativeness to GroovyClassDoc
    seems related to a poorly designed modeled, it can certainly be even
    faster.

commit 45e3225485ef44385ff7aa3759c2c63932e088f2
Author: Cedric Champeau <cc...@...>
Date:   2018-05-23T10:03:18Z

    Precompile some regular expressions

commit 31c93d6755814953e6eb0e92875ffafb8d33b060
Author: Cedric Champeau <cc...@...>
Date:   2018-05-23T10:12:21Z

    Cache external class lookup

----


---

[GitHub] groovy pull request #719: Optimize generation of Groovydoc

[asfgit <gi...@git.apache.org>]

Github user asfgit closed the pull request at:

    https://github.com/apache/groovy/pull/719


---