Arghhh time for bed:
Number is 179 vs 150 but I only ran it once so the numbers might be
completely bogus!
Tom
On 24.03.14 23:40, Tom Schindl wrote:
> Ups there was an error in my test for the last Call line so the numbers
> there are:
>
> 38 (lambda) vs 32 (subclass)
>
>> package hello;
>>
>>
Ups there was an error in my test for the last Call line so the numbers
there are:
38 (lambda) vs 32 (subclass)
> package hello;
>
> import java.util.ArrayList;
> import java.util.List;
> import java.util.concurrent.atomic.AtomicInteger;
> import java.util.function.Consumer;
>
> import javafx.b
The code I run is attached in the mail copy it to your env and run it
and flip the testLambda from true to false.
I might have been something dumb wrong but this is what I came up with.
Tom
On 24.03.14 23:31, Kevin Rushforth wrote:
> Those results are surprising. Is this an apples-to-apples comp
Those results are surprising. Is this an apples-to-apples comparison
with the only difference being a Lambda versus an equivalent anonymous
inner class?
-- Kevin
Tom Schindl wrote:
Hi,
I've written a small sample to see what it gets me to check:
* creation overhead
* memory overhead
* call
Hi,
I've written a small sample to see what it gets me to check:
* creation overhead
* memory overhead
* call overhead
I'm not very good at this kind of thing so someone who knows to write
benchmarks might know a lot better - need to check out JMH most likely.
Anyways here are the numbers:
Topi
On Sat, Mar 22, 2014 at 4:41 PM, Tom Schindl
wrote:
> Ah i missed you passing them to the constructor.
>
> Still i don't see this as much an improvement because we still create a vast
> amount of anon inner classes.
Sure, I just wanted to get the baseline for comparison right.
Tomas
>
> Tom
>
Ah i missed you passing them to the constructor.
Still i don't see this as much an improvement because we still create a vast
amount of anon inner classes.
Tom
Von meinem iPhone gesendet
> Am 22.03.2014 um 16:23 schrieb Tom Schindl :
>
> Why not i expect the property to be fully initialize so
Why not i expect the property to be fully initialize so this would be a
breaking change in behavior.
Tom
Von meinem iPhone gesendet
> Am 22.03.2014 um 14:54 schrieb Tomas Mikula :
>
> On Fri, Mar 21, 2014 at 8:53 PM, Tom Schindl
> wrote:
>> Hi Richard,
>>
>> Coming back to this old thread an
On Fri, Mar 21, 2014 at 8:53 PM, Tom Schindl
wrote:
> Hi Richard,
>
> Coming back to this old thread and now that we are using lamdas all over
> I guess we could take one more look into that.
>
> I've prototyped an initial version by introducing a new internal type
> named InvalidatedSimpleObjectP
It does seem promising. We'll also need data to show the trade-offs to
help inform whether it is worth making such a massive change.
-- Kevin
Stephen F Northover wrote:
This looks good. I wonder if we should make this (massive) change
before we lambda graphics and controls? Probably doesn't
This looks good. I wonder if we should make this (massive) change
before we lambda graphics and controls? Probably doesn't matter. We'll
need a JIRA and someone assigned to it in order to track the work.
Steve
On 2014-03-21 12:53 PM, Tom Schindl wrote:
Hi Richard,
Coming back to this old t
Cool. What we then need to measure is the impact to dynamic footprint (i.e.:
heap usage). Do the extra 3 fields per property object (bean, name, invalidated
method) have any significant impact? Or are these property instances created so
infrequently that it doesn’t make any real difference?
Ric
Hi Richard,
Coming back to this old thread and now that we are using lamdas all over
I guess we could take one more look into that.
I've prototyped an initial version by introducing a new internal type
named InvalidatedSimpleObjectProperty (not the best name ever!) - see
code pasted below.
And n
13 matches
Mail list logo
