Grails

Make certain parts of the build and startup process concurrent (for faster startup, war packaging tec) with GPars (which is in groovy standard now) easily

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.0-RC2
  • Fix Version/s: 2.3-M2
  • Component/s: None
  • Labels:
    None
  • Environment:
    All

Description

I noticed that running certain scripts, like run-war utilize only 25% CPU on my machine. As it has a blazing fast SSD I can assure you its just waiting for this one thread and i am wasting 75% drinking coffee

As the newest groovy release makes concurrency a piece of cake, someone with knowledge of grails scripts could speed up some of the build scripts by 2-8x+ depending on the amount of your cores. I imagine scanning and compiling plugin dirs can be done in parallel.

Parallelizing to 4 threads is as easy as:

GParsPool.withPool(4) { p ->
MyPluginCollection.eachParallel

{ ... }

}

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andre added a comment -

This methods not very accurate, but it should indicate in what components optimization potential lies:

Table shows summed up time in milliseconds from one trace/debug event to the next one. This is for a pretty much empty project with some popular plugins installed. There is no difference with -noreloading switch or prod environment.

spring.ReloadAwareAutowireCapableBeanFactory 16795.5
beans.CachedIntrospectionResults 11696.1
support.DefaultListableBeanFactory 4338.4
env.StandardEnvironment 3857.7
spring.DefaultRuntimeSpringConfiguration 1503.4
support.StandardServletEnvironment 1418.4
jdbc.AbstractBatcher 996.1
type.BasicTypeRegistry 966.3
support.TransactionSynchronizationManager 898.8
support.PathMatchingResourcePatternResolver 772.6
def.AbstractFlushingEventListener 678.9
loader.Loader 640.4
impl.SessionImpl 633.0
spring.GrailsWebApplicationContext 549.0

Show
Andre added a comment - This methods not very accurate, but it should indicate in what components optimization potential lies: Table shows summed up time in milliseconds from one trace/debug event to the next one. This is for a pretty much empty project with some popular plugins installed. There is no difference with -noreloading switch or prod environment. spring.ReloadAwareAutowireCapableBeanFactory 16795.5 beans.CachedIntrospectionResults 11696.1 support.DefaultListableBeanFactory 4338.4 env.StandardEnvironment 3857.7 spring.DefaultRuntimeSpringConfiguration 1503.4 support.StandardServletEnvironment 1418.4 jdbc.AbstractBatcher 996.1 type.BasicTypeRegistry 966.3 support.TransactionSynchronizationManager 898.8 support.PathMatchingResourcePatternResolver 772.6 def.AbstractFlushingEventListener 678.9 loader.Loader 640.4 impl.SessionImpl 633.0 spring.GrailsWebApplicationContext 549.0
Hide
Permalink
Andre added a comment -

trace/debug log as excel file

Show
Andre added a comment - trace/debug log as excel file

People

  • Assignee:
    Unassigned
    Reporter:
    Andre
Vote (4)
Watch (5)

Dates

  • Created:
    Updated:
    Last Reviewed: