headers
Martin C. Martin | 1 Jun 2009 13:13

[groovy-dev] Status of dynamic type promotion

Hi all,

What's the status of dynamic type promotion?  Any integral expression 
that would overflow returns a larger type (int -> long -> BigInteger) 
instead?  And introduce a syntax for "unchecked blocks" that will have 
Java's "wrap around" semantics?

I notice that GROOVY-3478 hasn't been applied yet.  Will that be applied 
soon?

Best,
Martin

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

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 12 comments |
headers
Russel Winder | 1 Jun 2009 16:10
Gravatar

[groovy-dev] Redundant code ? Efficiency ?

At first sight the method:

	org.codehaus.groovy.ant.Groovy.printResults ( PrintStream )

prints out two newlines in a very inefficient way.  Or am I missing
something deep and subtle?

Question 2 is whether all StringBuffer should now be replaced with
StringBuilder, thereby cutting out lots of inefficiency at a stroke --
and probably noticeably speeding up Groovy.

(Assuming that the use of StringBuffer is not deeply tied in to making
Groovy thread safe that is :-)

--

-- 
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:russel.winder <at> ekiga.net
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder
Permalink | Reply | 9 comments |
headers
Hamlet D'Arcy | 1 Jun 2009 16:54
Picon

Re: [groovy-dev] Redundant code ? Efficiency ?

> prints out two newlines in a very inefficient way.  Or am I missing
> something deep and subtle?

That is the strangest way I've ever seen 2 newlines printed!

> (Assuming that the use of StringBuffer is not deeply tied in to making
> Groovy thread safe that is :-)

Almost any local variable declaration of StringBuffer can be replaced
by StringBuilder as long as it never escapes the method. Once the
instance escapes, however, it can be very hard to reason about whether
it is threadsafe to replace it. It can escape as either a return value
or passed off to a new method. Replacing field declarations can
usually be reasoned about given, again, that the instance never
escapes.

> and probably noticeably speeding up Groovy.

Really?

On Mon, Jun 1, 2009 at 9:10 AM, Russel Winder
<russel.winder@...> wrote:
> At first sight the method:
>
>        org.codehaus.groovy.ant.Groovy.printResults ( PrintStream )
>
> prints out two newlines in a very inefficient way.  Or am I missing
> something deep and subtle?
>
> Question 2 is whether all StringBuffer should now be replaced with
(Continue reading)

Permalink | Reply | 5 comments |
headers
Russel Winder | 1 Jun 2009 17:10
Gravatar

Re: [groovy-dev] Redundant code ? Efficiency ?

On Mon, 2009-06-01 at 09:54 -0500, Hamlet D'Arcy wrote:
> > prints out two newlines in a very inefficient way.  Or am I missing
> > something deep and subtle?
> 
> That is the strangest way I've ever seen 2 newlines printed!

OK, its not just me then.

I am wondering if we can just delete the method entirely.  (I like
deleting code and having there be no test failures :-)

> > (Assuming that the use of StringBuffer is not deeply tied in to making
> > Groovy thread safe that is :-)
> 
> Almost any local variable declaration of StringBuffer can be replaced
> by StringBuilder as long as it never escapes the method. Once the
> instance escapes, however, it can be very hard to reason about whether
> it is threadsafe to replace it. It can escape as either a return value
> or passed off to a new method. Replacing field declarations can
> usually be reasoned about given, again, that the instance never
> escapes.

Exactly. It just requires someone to have the time and do it :-)

> > and probably noticeably speeding up Groovy.
> 
> Really?

StringBuffer is "thread safe" which means it is monitored, which means
every operation on an instance requires obtaining its lock, which is
(Continue reading)

Permalink | Reply | 4 comments |
headers
Russel Winder | 1 Jun 2009 17:50
Gravatar

[groovy-dev] Sanity check

I had thought that if statements now returned values (the value of the
last statement executed), is this true or not?
--

-- 
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:russel.winder <at> ekiga.net
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder
Permalink | Reply | 10 comments |
headers
Peter Niederwieser | 1 Jun 2009 18:08
Picon
Gravatar

[groovy-dev] Re: Re[groovy-dev] dundant code ? Efficiency ?


Russel Winder-4 wrote:
> 
> Question 2 is whether all StringBuffer should now be replaced with
> StringBuilder, thereby cutting out lots of inefficiency at a stroke --
> and probably noticeably speeding up Groovy.
> 

I'm wondering if it's worth it. According to Brian Goetz, the introduction
of StringBuilder was a case of premature optimization, and its usage won't
result in a noticeable speedup in Java 6 and above (because the JVM is smart
enough to optimize away the synchronization if not needed). Disclaimer: I'm
just repeating Brian's words from one of his JavaPolis/Devoxx talks
(hopefully), but haven't done any experiments myself.

Cheers,
Peter

--

-- 
View this message in context: http://www.nabble.com/Redundant-code----Efficiency---tp23815604p23817506.html
Sent from the groovy - dev mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 2 comments |
headers
Jochen Theodorou | 1 Jun 2009 18:29
Picon
Gravatar

Re: [groovy-dev] Sanity check

Russel Winder schrieb:
> I had thought that if statements now returned values (the value of the
> last statement executed), is this true or not?

they should, yes... from your mail I assume that is not the case. Have 
you a simple example?

bye blackdrag

--

-- 
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

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

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 0 comments |
headers
Jochen Theodorou | 1 Jun 2009 18:35
Picon
Gravatar

Re: [groovy-dev] Redundant code ? Efficiency ?

Russel Winder schrieb:
> On Mon, 2009-06-01 at 09:54 -0500, Hamlet D'Arcy wrote:
>>> prints out two newlines in a very inefficient way.  Or am I missing
>>> something deep and subtle?
>> That is the strangest way I've ever seen 2 newlines printed!
> 
> OK, its not just me then.
> 
> I am wondering if we can just delete the method entirely.  (I like
> deleting code and having there be no test failures :-)

the method s protected, so maybe not deleting it right away, but 
deprecating it and maybe replacing it with throwing our 
DeprecationException might be a good idea.

[...]
>>> and probably noticeably speeding up Groovy.

if we can remove the method because it is not used, then giving a 
different implementation will not change Groovy performance much

bye blackdrag

--

-- 
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Russel Winder | 1 Jun 2009 18:54
Gravatar

Re: [groovy-dev] Re: Re[groovy-dev] dundant code ? Efficiency ?

On Mon, 2009-06-01 at 09:08 -0700, Peter Niederwieser wrote:
[ . . . ]
> I'm wondering if it's worth it. According to Brian Goetz, the introduction
> of StringBuilder was a case of premature optimization, and its usage won't
> result in a noticeable speedup in Java 6 and above (because the JVM is smart
> enough to optimize away the synchronization if not needed). Disclaimer: I'm
> just repeating Brian's words from one of his JavaPolis/Devoxx talks
> (hopefully), but haven't done any experiments myself.

On the one hand Brian Goetz is a man whose words on Java can generally
be trusted to be right (so there is no need to worry and likely no
effect).  On the other hand the Java Collections were deliberately made
without monitors so as to make them efficient for single-threaded usage.
It could be that StringBuilder is a special case of premature
optimization, on the other hand why use a thread-safe data structure
when you don't need to.

Relying on the implementation of the JVM means you are relying on the
implementation of the JVM and not all implementations of the JVM are
equal.

All in all I prefer to use StringBuilder unless it is a known
multi-threaded situation where StringBuilder is the safer option.

--

-- 
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
(Continue reading)

Permalink | Reply | 1 comment |
headers
Russel Winder | 1 Jun 2009 19:00
Gravatar

Re: [groovy-dev] Redundant code ? Efficiency ?

On Mon, 2009-06-01 at 18:35 +0200, Jochen Theodorou wrote:
> Russel Winder schrieb:
> > On Mon, 2009-06-01 at 09:54 -0500, Hamlet D'Arcy wrote:
> >>> prints out two newlines in a very inefficient way.  Or am I missing
> >>> something deep and subtle?
> >> That is the strangest way I've ever seen 2 newlines printed!
> > 
> > OK, its not just me then.
> > 
> > I am wondering if we can just delete the method entirely.  (I like
> > deleting code and having there be no test failures :-)
> 
> the method s protected, so maybe not deleting it right away, but 
> deprecating it and maybe replacing it with throwing our 
> DeprecationException might be a good idea.

Is there a standard template replacement?  Commenting out the current
method to replace with an instantiated standard template sounds like a
good move.

> [...]
> >>> and probably noticeably speeding up Groovy.
> 
> if we can remove the method because it is not used, then giving a 
> different implementation will not change Groovy performance much

Removing this use of StringBuffer won't make any difference at all to
anything I suspect as it is never run.  My comment was really that if we
replace use of StringBuffer everywhere that is guaranteed thread safe
with use of StringBuilder then we should see some improvement.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane