Groovy performance: what to do

[Jochen Theodorou]

Martin C. Martin schrieb:

>
>
> Jochen Theodorou wrote:
>> Martin C. Martin schrieb:
>> [...]
>>> You can think of the current method resolution like this:
>>>
>>> (1) send the types to the metaclass and have it figure out what
>>> method to invoke.
>>>
>>> With the first proposal, this becomes:
>>>
>>> (2)
>>>     if (types & metaclass are as expected) {
>>>        call associated method
>>>     } else {
>>>        send the types to the metaclass and have it figure out what
>>>        method to invoke.
>>>     }
>>>
>>> The question is: if the programmer says they expect certain types &
>>> metaclass, but at runtime we find something different, is that an error?
>>
>> if you want to keep the current way, then no. Not unless you add
>> additional syntax for extended checks.
>
> Sorry, I'm not being very clear.  When I said "error" I was talking
> about the programmer's intentions, I should have said "mistake" instead.
>  In other words, I'm saying there are times when you want the extended
> checks (and other times you don't.)  In those cases, it would be more
> helpful for the runtime to signal an error than to continue on with
> unintended (but valid according to the specs) semantics.

well, if the rhs type is known and the lhs has a type, then we could
check if the types are assignable, because you can not change the
assignment at runtime. But to what cases would this apply to?

int i="aa"

the rhs is a constant, so we know the type for sure, we could throw an
error here.

int i = foo()

In this case you would normally use the return type of foo() to do the
check, but we that type is always to take of a grain of salt. If foo
returns Object, then the cast may succeed, if foo() return String, hen
it still might be replaced at runtime... We can't be sure if it will fail.

int i = j

in this case, if j is a local variable, we normally have a type, and we
could say if j is a String we can throw an error. If j is an Object we
can not. If j is a field, the same logic applies and if j is a property,
then we can't do anything, because it is just like a method call.

So as I see it such a check is possible in some cases, but they are not
very useful. We could check assignment of constants, local variables and
fields.

[...]
> It sounds like you don't want to give the programmer the ability to
> override the default behavior.  You don't want the programmer to be able
> to say "just find the method based on these types.  Even if you can't
> prove it at compile time, trust me, these really are the types."

because such a call could not be influenced by any dynamic mechanism we
have. I am not saying I do not want that, but we must be careful how to
do something like that.

> You
> always want to check the declared types, in case the programmer makes a
> mistake.  Essentially, when it comes to typing for efficiency, you never
> want to disable what amount to assertions.  Am I understanding correctly?

I am not checking the types in case the programmer makes a mistake, I
must check the types, because the runtime type might differ form the
expected type. For example if you declare something to be Object, then
it could still be a String or a JFrame or whatever. If I now call a
method that is overloaded with a String parameter, then I have to call
this method instead if my argument is a String.

> I can see why you'd want to do that in places where performance isn't
> critical, as with any assertion.  Perhaps it is a differing philosophy,
> but it makes sense to me to be able to turn those off in the small
> amount of code that's a performance bottleneck.

Of course I am concerned about performance, but in the first place I am
concerned about correctness. Of course, if the method call is annotated
or something so that the normal logic does not apply, then we can do
other things, but such an annotation is a syntactic element that is
always not so easy to add. You see there are two levels here, the
implementation and the syntax. A change to the implementation is easy,
as long as the semantics are the same. A change to the syntax is not
easy, because it must fit into many heads. Take the annotation Alex
proposed for example. No developer is against enabling direct calls if
they are marked and recognizable and such. But to be recognized you need
a syntax and the syntax is the problem.

So I am trying to make the implementation side faster, which reduces the
need for such a syntax.

bye blackdrag

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

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

    http://xircles.codehaus.org/manage_email

[Martin C. Martin]

>>> let us make this more easy by making it more special. Let us say
>>> there is a way to say that always the default MetaClass will be used
>>> for all objects. In that case we could for final classes and if all
>>> types of all parameters are known generate a static call without
>>> loosing semantic. final because of our multi methods. With this it
>>> can be can be considered as rare case.
>>
>> That sounds great.  Do you think this is worth implementing, or would
>> the case be too rare?  Also, would the classes need to be final if
>> mixed with the casting syntax as above?  I think this could lead to
>> its use in cases that are a lot less rare.
>
> there is another class of methods that could theoretically be called
> directly and that is private methods. And I think implementing this for
> private methods is worth it, the implementation for other methods would
> be a side product then. Ah yes.. not the method needs to be final, the
> class needs to be, because this way we can be sure there will be no
> subclass adding a method... but I guess we can't work around the check
> here too.. because it is always possible, that the MetaClass got a new
> overloading or replacing method.... so this check has to check at last
> the MetaClass for being the default.

Yes, but I think it is a common case that this doesn't change at
runtime.  So I think having all of that will help.

Best,
Martin

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

    http://xircles.codehaus.org/manage_email