Grails
  1. Grails
  2. GRAILS-8412

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
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0-RC2
    • Fix Version/s: None
    • 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

        Hide
        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
        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
          • Votes:
            4 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Last Reviewed:

              Development