gmane.comp.lang.groovy.devel

Russel Winder | 20 Aug 08:17

[groovy-dev] Startup cost -- just checking, not a huge issue -- mainly for interest

I know my Sun Blade 100 is old (5 years) and slow but...

|> JAVACMD=/usr/jdk/latest/bin/sparcv9/java time groovy -e "println
System.getProperty('sun.arch.data.model')"
64

real       17.4
user       14.1
sys         2.1
|> JAVACMD=/usr/jdk/latest/bin/sparcv9/java time groovy -e "println
System.getProperty('sun.arch.data.model')"
64

real       16.0
user       13.8
sys         1.3
|> time groovy -e "println System.getProperty('sun.arch.data.model')"
32

real    0m12.847s
user    0m9.287s
sys     0m1.506s
|> time groovy -e "println System.getProperty('sun.arch.data.model')"
32

real    0m11.417s
user    0m9.237s
sys     0m1.447s
|>

(Continue reading)

headers

Martin C. Martin | 20 Aug 14:15

Re: [groovy-dev] Startup cost -- just checking, not a huge issue -- mainly for interest

Hey Russel,

I used to have problems like this on Cygwin, it turns out that the 
startGroovy script was the problem.  IIRC, it does something like 
iterate over every directory in /, or all mounted volumes, or something. 
  As a local hack, I could just just inline the output of the command, 
since I wasn't adding any new drives.  Anyway, I suggest putting echo 
statements throughout startGroovy, to see if it's the problem, and if 
so, where the time is going.

Best,
Martin

Russel Winder wrote:
> I know my Sun Blade 100 is old (5 years) and slow but...
> 
> |> JAVACMD=/usr/jdk/latest/bin/sparcv9/java time groovy -e "println
> System.getProperty('sun.arch.data.model')"
> 64
> 
> real       17.4
> user       14.1
> sys         2.1
> |> JAVACMD=/usr/jdk/latest/bin/sparcv9/java time groovy -e "println
> System.getProperty('sun.arch.data.model')"
> 64
> 
> real       16.0
> user       13.8
> sys         1.3

(Continue reading)

headers

Russel Winder | 20 Aug 17:34

Re: [groovy-dev] Startup cost -- just checking, not a huge issue -- mainly for interest

Martin,

On Wed, 2008-08-20 at 08:15 -0400, Martin C. Martin wrote:
> Hey Russel,
> 
> I used to have problems like this on Cygwin, it turns out that the 
> startGroovy script was the problem.  IIRC, it does something like 
> iterate over every directory in /, or all mounted volumes, or something. 
>   As a local hack, I could just just inline the output of the command, 
> since I wasn't adding any new drives.  Anyway, I suggest putting echo 
> statements throughout startGroovy, to see if it's the problem, and if 
> so, where the time is going.

Certainly large shell scripts are generally a bad move, and startGroovy
is far from small.  However in this instance it is not the problem.
Executing the script with sh -x shows that it gets to the exec $JAVACMD
command really rather quickly.  It is definitely the case that the
problem is one or more of:

	1.  Loading the JVM
	2.  Initializing the JVM (supposedly less of a problem in 1.6 but...
	3.  Initializing the Groovy infrastructure.
	4.  Running the code.

My hypothesis is 3 is the major culprit.  Though the huge difference
between Solaris on the one hand and Linux/Mac OS X on the other cannot
be entirely explained by slower/faster processor, there may be an
element of 1 and 2 in the case of Solaris.  I believe most of the
startup effort has gone into Windows and Linux builds, on the assumption
that Solaris builds are generally for servers which are usually running

(Continue reading)

headers

Nick Sieger | 20 Aug 17:48

Re: [groovy-dev] Startup cost -- just checking, not a huge issue -- mainly for interest

On Wed, Aug 20, 2008 at 10:34 AM, Russel Winder
<russel.winder@...> wrote:
>
> Certainly large shell scripts are generally a bad move, and startGroovy
> is far from small.  However in this instance it is not the problem.
> Executing the script with sh -x shows that it gets to the exec $JAVACMD
> command really rather quickly.  It is definitely the case that the
> problem is one or more of:
>
>        1.  Loading the JVM
>        2.  Initializing the JVM (supposedly less of a problem in 1.6 but...
>        3.  Initializing the Groovy infrastructure.
>        4.  Running the code.
>
> My hypothesis is 3 is the major culprit.  Though the huge difference
> between Solaris on the one hand and Linux/Mac OS X on the other cannot
> be entirely explained by slower/faster processor, there may be an
> element of 1 and 2 in the case of Solaris.  I believe most of the
> startup effort has gone into Windows and Linux builds, on the assumption
> that Solaris builds are generally for servers which are usually running
> rather than starting up.

In JRuby we got a noticeable startup improvement from loading JRuby
classes in the boot classpath, thereby avoiding class verification.
Have you ruled it out already?

> (Any Sun budget holders listening who want to gift me a really cool
> parallel Sun box? 

Tim Bray would probably give you an account on his wide-finder machine

(Continue reading)

headers

Miguel Duarte | 20 Aug 19:13

Re: [groovy-dev] Startup cost -- just checking, not a huge issue -- mainly for interest

Tim Bray would probably give you an account on his wide-finder machine
(T515x) for testing, possibly in return for Groovy-related
contributions to the WF project :)

http://wikis.sun.com/display/WideFinder/Wide+Finder+Home

(...)
During a presentation about "Scripting in the JVM" at the Portuguese JUG I did a groovy WideFinder - not really wide, but the point I was trying to make is that Groovy has a really neat syntax :-)

/*
    Groovy Widefinder implementation
    Miguel Duarte
    malduarte at gmail dot com
*/
urls = [:]
m = "" =~ 'GET /ongoing/When/\\d{3}x/(\\d{4}/\\d\\d/\\d\\d/[^ .]+) '

new File(args[0]).eachLine {
    if(m.reset(it).find()) {
        total = urls[m.group(1)]
        urls[m.group(1)] = total == null ? 1 : ++total
    }
}

urls.entrySet().sort{-it.value}[0..10].each{
    println it
}

headers

Martin C. Martin | 20 Aug 14:17

Re: [groovy-dev] Startup cost -- just checking, not a huge issue -- mainly for interest

Here's the offending line:

     ROOTDIRSRAW=`find -L / -maxdepth 1 -mindepth 1 -type d 2>/dev/null`

But its in a "cygwin only" section, so I guess it's not your problem. 
Still, maybe something else in startGroovy is...

Best,
Martin

Russel Winder wrote:
> I know my Sun Blade 100 is old (5 years) and slow but...
> 
> |> JAVACMD=/usr/jdk/latest/bin/sparcv9/java time groovy -e "println
> System.getProperty('sun.arch.data.model')"
> 64
> 
> real       17.4
> user       14.1
> sys         2.1
> |> JAVACMD=/usr/jdk/latest/bin/sparcv9/java time groovy -e "println
> System.getProperty('sun.arch.data.model')"
> 64
> 
> real       16.0
> user       13.8
> sys         1.3
> |> time groovy -e "println System.getProperty('sun.arch.data.model')"
> 32
> 
> real    0m12.847s
> user    0m9.287s
> sys     0m1.506s
> |> time groovy -e "println System.getProperty('sun.arch.data.model')"
> 32
> 
> real    0m11.417s
> user    0m9.237s
> sys     0m1.447s
> |> 
> 
> I tried it also on a 3GHZ Pentium 4:
> 
> |> time groovy -e "println System.getProperty('sun.arch.data.model')"
> 32
> 
> real	0m2.125s
> user	0m1.976s
> sys	0m0.136s
> |> time groovy -e "println System.getProperty('sun.arch.data.model')"
> 32
> 
> real	0m2.033s
> user	0m1.996s
> sys	0m0.152s
> |> 
> 
> and a twin 2.33GHz Xeon:
> 
> |>  time groovy -e "println System.getProperty('sun.arch.data.model')"
> 32
> 
> real	0m0.862s
> user	0m1.328s
> sys	0m0.088s
> |>  time groovy -e "println System.getProperty('sun.arch.data.model')"
> 32
> 
> real	0m0.910s
> user	0m1.316s
> sys	0m0.100s
> |> 
> 
> Note how the amount of time in user space is longer than the elapse
> time 
> 
> Confirmation that doing things twice is a good idea comes on Mac Mini:
> 
> |>  time groovy -e "println System.getProperty('sun.arch.data.model')"
> 32
> 
> real	0m7.333s
> user	0m1.392s
> sys	0m0.217s
> |>  time groovy -e "println System.getProperty('sun.arch.data.model')"
> 32
> 
> real	0m1.755s
> user	0m1.387s
> sys	0m0.135s
> |> 
> 
> I would say that getting this < 0.2s is the magic figure for usability.
> So I just need bigger faster machines 
> 

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

headers

Russel Winder | 20 Aug 17:43

Re: [groovy-dev] Startup cost -- just checking, not a huge issue -- mainly for interest

On Wed, 2008-08-20 at 08:17 -0400, Martin C. Martin wrote:
> Here's the offending line:
> 
>      ROOTDIRSRAW=`find -L / -maxdepth 1 -mindepth 1 -type d 2>/dev/null`
> 
> But its in a "cygwin only" section, so I guess it's not your problem. 
> Still, maybe something else in startGroovy is...

This shouldn't take that long, but then again it is Cygwin on Windows.

Almost all of the hassles with the Posix launch scripts for Groovy (and
Gant) are caused by Cygwin.  I often wonder if the hassle of supporting
Cygwin, Mac OS X and other Posix compliant shells in the same script is
actually worth it.  I wonder if we might consider a deconstruction of
the script more than already happens so as to try and minimize the code
executed.

Certainly for known distributions such as Debian, Ubuntu, Fedora,
CentOS, Red Hat, SuSE, etc. packagers normally replace the distributed
scripts with distribution-specific, hardwired scripts so as to ensure
the minimum number of steps.

I think though that leaving this as the responsibility of the packagers
is the right thing to do.  So in this case we should be trying to get
Groovy into the Cygwin distribution.  Groovy is already in Debian and
Ubuntu, don't know about Fedora, CentOS,  Red Hat (centOS) and Suse.  If
it isn't we should lobby.

--

-- 
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077