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:
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
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
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
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;
import
On Fri, Mar 21, 2014 at 8:53 PM, Tom Schindl
tom.schi...@bestsolution.at 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
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 tomas.mik...@gmail.com:
On Fri, Mar 21, 2014 at 8:53 PM, Tom Schindl
tom.schi...@bestsolution.at wrote:
Hi
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 tom.schi...@bestsolution.at:
Why not i expect the property
On Sat, Mar 22, 2014 at 4:41 PM, Tom Schindl
tom.schi...@bestsolution.at 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
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
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?
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
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
13 matches
Mail list logo
