Am 14.05.2012 17:19, schrieb Charles Oliver Nutter:
> On Mon, May 14, 2012 at 4:32 AM, Jochen Theodorou wrote:
>> That it is slower at first is ok. Only I kind of assumed, that such
>> things can be optimized away. The less the JIT can optimize, the more I
>> have to do that and work around the li
On Mon, May 14, 2012 at 4:32 AM, Jochen Theodorou wrote:
> That it is slower at first is ok. Only I kind of assumed, that such
> things can be optimized away. The less the JIT can optimize, the more I
> have to do that and work around the limitations, making my runtime more
> complex. And with the
On Mon, May 14, 2012 at 4:30 AM, Jochen Theodorou wrote:
> the special paths with guards in bytecode is actually a thing I was
> hoping to get rid of with indy. The current state of the implementation
> of indy in Groovy is, that it is slightly better than our call site
> caching and worse than ou
Am 14.05.2012 08:55, schrieb Rémi Forax:
[...]
>> so you mean to tell me that I have first to convert the Object to an
>> Integer and that Integer to int, instead of directly converting the
>> Object to an int? I see, I will try that out.
>
> Yes.
> You should not have to do that because you first
Am 14.05.2012 01:16, schrieb Mark Roos:
[...]
> So I decided that all my ints will be boxed (references), added a cache
> and some special prim
> methods for now and then follow Charles approach of a good indy design
> to take advantage
> of the optimization efforts. Based on my large scale benchma
