Cost of creating objects?

Discussion in 'Java' started by Sebastian, Aug 7, 2013.

  1. Sebastian

    Sebastian Guest

    @Override
    public int compare(AttrValue o1, AttrValue o2)
    {
    Long ts1 = o1.getEffectiveSequenceNumber(); // ??
    Long ts2 = o2.getEffectiveSequenceNumber(); // ??
    return ts1.compareTo(ts2);
    }

    Would you expect a measureable impact of creating these
    variables ts1, ts2, instead of "inlining" the calls to
    getEffectiveSequenceNumber(). (Using JDK 6?)

    How can I reason about this things, probably influenced by
    JIT, without doing actually measurements, say as part of a
    code inspection?

    -- Sebastian
    Sebastian, Aug 7, 2013
    #1
    1. Advertising

  2. Sebastian

    Sebastian Guest

    Am 07.08.2013 12:02, schrieb Donkey Hottie:
    > 07.08.2013 10:44, Sebastian kirjoitti:
    >> @Override
    >> public int compare(AttrValue o1, AttrValue o2)
    >> {
    >> Long ts1 = o1.getEffectiveSequenceNumber(); // ??
    >> Long ts2 = o2.getEffectiveSequenceNumber(); // ??
    >> return ts1.compareTo(ts2);
    >> }
    >>
    >> Would you expect a measureable impact of creating these
    >> variables ts1, ts2, instead of "inlining" the calls to
    >> getEffectiveSequenceNumber(). (Using JDK 6?)
    >>
    >> How can I reason about this things, probably influenced by
    >> JIT, without doing actually measurements, say as part of a
    >> code inspection?
    >>
    >> -- Sebastian
    >>

    >
    > What is getEffectiveSequenceNumber() returning?
    >
    > If Long, there is no way to prevent the creation of a Long.
    >
    > If long, try and use long variables instead, and manually code the
    > comparison code, it's not that complicated anyway.
    >


    Thanks for the hint, yes, I forgot to state that the method returns a
    long primitive.

    However, your answer does not address my question, which wasn't about
    how to code a long comparison.

    -- Sebastian
    Sebastian, Aug 7, 2013
    #2
    1. Advertising

  3. Sebastian

    Joerg Meier Guest

    On Wed, 07 Aug 2013 09:44:53 +0200, Sebastian wrote:

    > @Override
    > public int compare(AttrValue o1, AttrValue o2)
    > {
    > Long ts1 = o1.getEffectiveSequenceNumber(); // ??
    > Long ts2 = o2.getEffectiveSequenceNumber(); // ??
    > return ts1.compareTo(ts2);
    > }


    > Would you expect a measureable impact of creating these
    > variables ts1, ts2, instead of "inlining" the calls to
    > getEffectiveSequenceNumber(). (Using JDK 6?)


    I would expect the JIT to inline them for you if the method is called more
    than a handful of times.

    > How can I reason about this things, probably influenced by
    > JIT, without doing actually measurements, say as part of a
    > code inspection?


    You probably can't, nor will you find a huge audience to reason with you on
    a topic like this, because it's so obviously pointless. If your performance
    bottleneck is assigning temporary local variables, then Java simply isn't
    the right language for whatever task you are doing, and I would expect most
    people to hold similar views.

    Liebe Gruesse,
    Joerg

    --
    Ich lese meine Emails nicht, replies to Email bleiben also leider
    ungelesen.
    Joerg Meier, Aug 7, 2013
    #3
  4. Sebastian

    Eric Sosman Guest

    On 8/7/2013 6:05 AM, Sebastian wrote:
    > Am 07.08.2013 12:02, schrieb Donkey Hottie:
    >> 07.08.2013 10:44, Sebastian kirjoitti:
    >>> @Override
    >>> public int compare(AttrValue o1, AttrValue o2)
    >>> {
    >>> Long ts1 = o1.getEffectiveSequenceNumber(); // ??
    >>> Long ts2 = o2.getEffectiveSequenceNumber(); // ??
    >>> return ts1.compareTo(ts2);
    >>> }
    >>>
    >>> Would you expect a measureable impact of creating these
    >>> variables ts1, ts2, instead of "inlining" the calls to
    >>> getEffectiveSequenceNumber(). (Using JDK 6?)
    >>>
    >>> How can I reason about this things, probably influenced by
    >>> JIT, without doing actually measurements, say as part of a
    >>> code inspection?
    >>>
    >>> -- Sebastian
    >>>

    >>
    >> What is getEffectiveSequenceNumber() returning?
    >>
    >> If Long, there is no way to prevent the creation of a Long.
    >>
    >> If long, try and use long variables instead, and manually code the
    >> comparison code, it's not that complicated anyway.
    >>

    >
    > Thanks for the hint, yes, I forgot to state that the method returns a
    > long primitive.
    >
    > However, your answer does not address my question, which wasn't about
    > how to code a long comparison.


    He answered part of your question, essentially saying "Don't
    create a Long if the returned long suits your purpose." If you
    can stick with long (which it seems you can), you can eliminate
    the creation and eventual collection of two Long objects. (But
    if getEffectiveSequenceNumber() does four hash table lookups,
    three regex matches, two Fourier transforms, and a database
    query, ... Even a hundred Long's would be "in the noise.")

    Primitive local variables are free, pretty nearly, but if
    you move to 1.7 you could even get rid of those:

    @Override
    public int compare(AttrValue o1, AttrValue o2)
    {
    return Long.compare( // New in 1.7
    o1.getEffectiveSequenceNumber(),
    o2.getEffectiveSequenceNumber());
    }

    Of course, the named primitives that disappear from your method
    may reappear as the named parameters of compare(), so it might
    just be a wash. I'd imagine that any difference would be so small
    as to be very difficult to measure.

    --
    Eric Sosman
    d
    Eric Sosman, Aug 7, 2013
    #4
  5. Sebastian

    Stefan Ram Guest

    Sebastian <> writes:
    >Would you expect a measureable impact of creating these
    >variables ts1, ts2, instead of "inlining" the calls to
    >getEffectiveSequenceNumber(). (Using JDK 6?)


    Creating objects on the heap is not so much effort, but
    eventual garbage collection might take some time. However,
    the compiler can perform an escape analysis and then
    create the objects on the stack. A smart compiler could
    even transform the code to the code written by Donkey.
    Therefore, programmers nowadays often do not ask
    »what is most efficient?«, but »what is most readable?«.
    Stefan Ram, Aug 7, 2013
    #5
  6. Sebastian

    Sebastian Guest

    Am 07.08.2013 17:39, schrieb Stefan Ram:
    > Sebastian<> writes:
    >> Would you expect a measureable impact of creating these
    >> variables ts1, ts2, instead of "inlining" the calls to
    >> getEffectiveSequenceNumber(). (Using JDK 6?)

    >
    > Creating objects on the heap is not so much effort, but
    > eventual garbage collection might take some time. However,
    > the compiler can perform an escape analysis and then
    > create the objects on the stack. A smart compiler could
    > even transform the code to the code written by Donkey.
    > Therefore, programmers nowadays often do not ask
    > »what is most efficient?«, but »what is most readable?«.
    >


    I would agree. The reason I asked is we have a person in our group
    who is very much in a micro-optimization mind-set. Among the things
    that concern him are, for example, temporary local variables, wrappers
    as method arguments wasting heap space compared to primitives,
    multiple hash map lookups (containsKey() followed by get()) etc.

    I sometimes find his code inelegant and unclear and would like to know
    that it cannot really be more efficient. But of course, I cannot
    rewrite and profile all his stuff in order to convince him.

    -- Sebastian
    Sebastian, Aug 7, 2013
    #6
  7. Sebastian

    Eric Sosman Guest

    On 8/7/2013 1:51 PM, Sebastian wrote:
    > [...] The reason I asked is we have a person in our group
    > who is very much in a micro-optimization mind-set. Among the things
    > that concern him are, for example, temporary local variables, wrappers
    > as method arguments wasting heap space compared to primitives,
    > multiple hash map lookups (containsKey() followed by get()) etc.
    >
    > I sometimes find his code inelegant and unclear and would like to know
    > that it cannot really be more efficient. But of course, I cannot
    > rewrite and profile all his stuff in order to convince him.


    Prediction: Without measurement, you won't convince him.

    Observation: Without measurement, perhaps neither of you
    *should* convince the other.

    Prediction II: ... but you'll both try anyhow. ;-)

    --
    Eric Sosman
    d
    Eric Sosman, Aug 7, 2013
    #7
  8. Sebastian

    Lew Guest

    Eric Sosman wrote:
    > Sebastian wrote:
    >> [...] The reason I asked is we have a person in our group
    >> who is very much in a micro-optimization mind-set. Among the things
    >> that concern him are, for example, temporary local variables, wrappers
    >> as method arguments wasting heap space compared to primitives,
    >> multiple hash map lookups (containsKey() followed by get()) etc.


    Overrule him. He's an idiot. Although doing a 'containsKey()' before a 'get()' is silly.

    The burden of proof is on him to prove where these things matter, and not by micro-
    benchmarks. Don't waste your time optimizing things that represent 0.00001% of program
    execution time after JIT gets its mitts on them. Don't do things that are silly
    (like checking 'containsKey()' just before a map 'get()' when 'null' is not an allowed value)
    and your program should run about as fast as it can.

    >> I sometimes find his code inelegant and unclear and would like to know
    >> that it cannot really be more efficient. But of course, I cannot


    You do not need to know that. You only need for him not to know that it assuredly
    is more efficient. If he cannot prove that, reject his silly suggestions. (Accept the ones that
    are not silly.)

    If he cannot prove that the "efficiency" is a real problem, and more importantly, that the cost
    of this "inefficiency" is larger than the cost of maintaining unclear code (in dollars and cents),
    then his suggestions must be rejected.

    >> rewrite and profile all his stuff in order to convince him.


    Not your job. It's his job to convince you.

    > Prediction: Without measurement, you won't convince him.


    Nor should you.

    > Observation: Without measurement, perhaps neither of you
    > *should* convince the other.


    Certainly without observations he should not try to convince you.

    > Prediction II: ... but you'll both try anyhow. ;-)


    You should convince him. Not that the code is sufficiently "efficient" now, but that the
    question is irrelevant. You won't convince him that he's an idiot, but maybe you will
    convince him to shut up.

    --
    Lew
    Lew, Aug 8, 2013
    #8
  9. Sebastian

    Arne Vajhøj Guest

    On 8/7/2013 3:44 AM, Sebastian wrote:
    > @Override
    > public int compare(AttrValue o1, AttrValue o2)
    > {
    > Long ts1 = o1.getEffectiveSequenceNumber(); // ??
    > Long ts2 = o2.getEffectiveSequenceNumber(); // ??
    > return ts1.compareTo(ts2);
    > }
    >
    > Would you expect a measureable impact of creating these
    > variables ts1, ts2, instead of "inlining" the calls to
    > getEffectiveSequenceNumber(). (Using JDK 6?)


    The difference between:

    Long ts1 = o1.getEffectiveSequenceNumber();
    Long ts2 = o2.getEffectiveSequenceNumber();
    return ts1.compareTo(ts2);

    and:

    return
    o1.getEffectiveSequenceNumber().compareTo(o2.getEffectiveSequenceNumber());

    should be nothing.

    The difference between:

    Long ts1 = o1.getEffectiveSequenceNumber();
    Long ts2 = o2.getEffectiveSequenceNumber();
    return ts1.compareTo(ts2);

    and doing something simple with long as described by other posters
    would be huge in a program not doing anything but this in a 1 billion
    times iteration but insignificant in most real world programs.

    > How can I reason about this things, probably influenced by
    > JIT, without doing actually measurements, say as part of a
    > code inspection?


    Experience will enable you to make qualified guesses.

    Measuring will tell you the facts.

    :)

    Arne
    Arne Vajhøj, Aug 8, 2013
    #9
  10. Sebastian

    Arne Vajhøj Guest

    On 8/7/2013 1:51 PM, Sebastian wrote:
    > Am 07.08.2013 17:39, schrieb Stefan Ram:
    >> Sebastian<> writes:
    >>> Would you expect a measureable impact of creating these
    >>> variables ts1, ts2, instead of "inlining" the calls to
    >>> getEffectiveSequenceNumber(). (Using JDK 6?)

    >>
    >> Creating objects on the heap is not so much effort, but
    >> eventual garbage collection might take some time. However,
    >> the compiler can perform an escape analysis and then
    >> create the objects on the stack. A smart compiler could
    >> even transform the code to the code written by Donkey.
    >> Therefore, programmers nowadays often do not ask
    >> »what is most efficient?«, but »what is most readable?«.
    >>

    >
    > I would agree. The reason I asked is we have a person in our group
    > who is very much in a micro-optimization mind-set. Among the things
    > that concern him are, for example, temporary local variables, wrappers
    > as method arguments wasting heap space compared to primitives,
    > multiple hash map lookups (containsKey() followed by get()) etc.
    >
    > I sometimes find his code inelegant and unclear and would like to know
    > that it cannot really be more efficient. But of course, I cannot
    > rewrite and profile all his stuff in order to convince him.


    Send him back to the 9970's or 1980's - there were great use
    for developers like him back then.

    Today that type of stuff typical make large chunks of code
    unreadable and saves little on overall execution time.

    But you may find it difficult to convince him. Microoptimizers
    believe very strongly in their religion.

    You can suggest every time he wants to change something that
    you measure the real application before and after the change.

    My guess is that he will find an excuse for not doing that and
    refer to his own micro-benchmark.

    Arne
    Arne Vajhøj, Aug 8, 2013
    #10
  11. Sebastian

    Eric Sosman Guest

    On 8/7/2013 7:52 PM, Lew wrote:
    > Eric Sosman wrote:
    >> Sebastian wrote:
    >>> [...] The reason I asked is we have a person in our group
    >>> who is very much in a micro-optimization mind-set. Among the things
    >>> that concern him are, for example, temporary local variables, wrappers
    >>> as method arguments wasting heap space compared to primitives,
    >>> multiple hash map lookups (containsKey() followed by get()) etc.

    >
    > Overrule him. He's an idiot. Although doing a 'containsKey()' before a 'get()' is silly.


    Situation: A Map that is searched for keys that are usually
    *not* present (poor man's Bloom filter, say), and some of whose
    mapped values are null. Now, attend:

    if (map.containsKey(key)) { // usually false
    Value val = map.get(key); // seldom needed
    ...
    }

    vs.

    Value val = map.get(key);
    if (val == null // usually true
    || map.containsKey(key) // usually false
    ) {
    ...
    }

    If the key is present 0.0 <= p <= 1.0 of the time, the first
    version does (1 + p) searches, the second (1 + (1 - p)) = (2 - p).
    Even if the second search is cheaper than the first (maybe the
    key's hashCode has been cached), for small p the first wins.

    --
    Eric Sosman
    d
    Eric Sosman, Aug 8, 2013
    #11
  12. In article <>,
    lipska the kat <"nospam at neversurrender dot co dot uk"> wrote:

    > On 07/08/13 08:44, Sebastian wrote:
    > > @Override
    > > public int compare(AttrValue o1, AttrValue o2)
    > > {
    > > Long ts1 = o1.getEffectiveSequenceNumber(); // ??
    > > Long ts2 = o2.getEffectiveSequenceNumber(); // ??
    > > return ts1.compareTo(ts2);
    > > }
    > >
    > > Would you expect a measureable impact of creating these
    > > variables ts1, ts2, instead of "inlining" the calls to
    > > getEffectiveSequenceNumber(). (Using JDK 6?)
    > >
    > > How can I reason about this things, probably influenced by
    > > JIT, without doing actually measurements, say as part of a
    > > code inspection?

    >
    > Have you heard of a profiler?
    >
    > A few years ago I used one to investigate an application running on
    > Weblogic application server, the results were eye opening.
    >
    > I seem to remember the company I was working for handed over a large wad
    > of cash to get a couple of licences for a commercial product ... can't
    > remember what it was called unfortunately.
    >
    > Googling 'java profiler' today returns the usual plethora of hits and I
    > expect the game has moved on since I last used one, there also appear to
    > be a bunch of free ones out there.
    >
    > If you want to reason about this stuff then it might pay you to have a
    > look at your application with a profiler, you will almost certainly
    > learn something to help you in your endeavors.
    >
    > lipska


    Most automatic Java profilers are a waste of effort. There are two
    methods supported by the JVM:

    1) Profiler instrumentation. This rewrites methods to contain timing
    calls. This rewriting and data collection breaks all the optimizations
    that are critical to Java performing well. Most can only collect data
    into a single thread so all concurrency is gone too. These only work
    when manually configured to target very specific points of code.


    2) Sampling. This takes rapid stack snapshots of each thread and
    collects statistics. It's simple and you can even build a JSP to do it.
    This also doesn't work for performance benchmarking because snapshots of
    native code require threads to stop at a safepoint. When HotSpot is
    doing a good job, safepoints come at regular intervals in the optimized
    native code, not your source code. When I use sampling profiling on a
    project at work, Integer.hashCode() sometimes leaps to the #1 spot.
    There's not actually any code in that method and it's not called very
    frequently, but often a safepoint's native address maps to that source
    in the debug symbol table. Sampling is best for finding code that
    pauses (I/O, semaphore, waiting for resource, etc.) for unexpectedly
    long times.

    As for the original question, variable declarations mean nothing in
    compiled code. They're just for humans. At times when AttrValue is
    known to have only one possible implementation, HotSpot may even inline
    the methods and use direct field access. Later when AttrValue may have
    more than one implementation, HotSpot can go remove that optimization.
    Kevin McMurtrie, Aug 8, 2013
    #12
  13. In article <ktt63o$l57$>,
    Sebastian <> wrote:

    > Am 07.08.2013 12:02, schrieb Donkey Hottie:
    > > 07.08.2013 10:44, Sebastian kirjoitti:
    > >> @Override
    > >> public int compare(AttrValue o1, AttrValue o2)
    > >> {
    > >> Long ts1 = o1.getEffectiveSequenceNumber(); // ??
    > >> Long ts2 = o2.getEffectiveSequenceNumber(); // ??
    > >> return ts1.compareTo(ts2);
    > >> }
    > >>
    > >> Would you expect a measureable impact of creating these
    > >> variables ts1, ts2, instead of "inlining" the calls to
    > >> getEffectiveSequenceNumber(). (Using JDK 6?)
    > >>
    > >> How can I reason about this things, probably influenced by
    > >> JIT, without doing actually measurements, say as part of a
    > >> code inspection?
    > >>
    > >> -- Sebastian
    > >>

    > >
    > > What is getEffectiveSequenceNumber() returning?
    > >
    > > If Long, there is no way to prevent the creation of a Long.
    > >
    > > If long, try and use long variables instead, and manually code the
    > > comparison code, it's not that complicated anyway.
    > >

    >
    > Thanks for the hint, yes, I forgot to state that the method returns a
    > long primitive.
    >
    > However, your answer does not address my question, which wasn't about
    > how to code a long comparison.
    >
    > -- Sebastian


    This:
    Long l= 4L;

    is shorthand for:

    Long l= Long.valueOf(4);

    It's optimized for some values to return a singleton. For others you'll
    get a performance penalty on Long creation. How big that is depends on
    your system. Run it a 100 million times and see.

    Since comparing the primitives is known to be fast and trivial, I'd just
    compare the primitives. There's no point writing potentially slow code
    for no good reason.
    Kevin McMurtrie, Aug 8, 2013
    #13
  14. Eric Sosman <> writes:
    > On 8/7/2013 7:52 PM, Lew wrote:


    >> Overrule him. He's an idiot. Although doing a 'containsKey()' before a
    >> get()' is silly.


    > Situation: A Map that is searched for keys that are usually
    > *not* present (poor man's Bloom filter, say), and some of whose
    > mapped values are null. Now, attend:


    > if (map.containsKey(key)) { // usually false
    > Value val = map.get(key); // seldom needed
    > ...
    > }
    > vs.
    > Value val = map.get(key);
    > if (val == null // usually true
    > || map.containsKey(key) // usually false
    > ) {


    I think you mean

    Value val = map.get(key);
    if (val != null // usually false
    || map.containsKey(key)) { // usually false

    --
    Jukka Lahtinen
    Jukka Lahtinen, Aug 8, 2013
    #14
  15. Sebastian

    Eric Sosman Guest

    On 8/8/2013 4:24 AM, Jukka Lahtinen wrote:
    > Eric Sosman <> writes:
    >> On 8/7/2013 7:52 PM, Lew wrote:

    >
    >>> Overrule him. He's an idiot. Although doing a 'containsKey()' before a
    >>> get()' is silly.

    >
    >> Situation: A Map that is searched for keys that are usually
    >> *not* present (poor man's Bloom filter, say), and some of whose
    >> mapped values are null. Now, attend:

    >
    >> if (map.containsKey(key)) { // usually false
    >> Value val = map.get(key); // seldom needed
    >> ...
    >> }
    >> vs.
    >> Value val = map.get(key);
    >> if (val == null // usually true
    >> || map.containsKey(key) // usually false
    >> ) {

    >
    > I think you mean
    >
    > Value val = map.get(key);
    > if (val != null // usually false
    > || map.containsKey(key)) { // usually false


    (Sigh.) Yes, indeed. That's what I get for writing once
    and then editing "for clarity" ...

    --
    Eric Sosman
    d
    Eric Sosman, Aug 8, 2013
    #15
  16. lipska the kat <"nospam at neversurrender dot co dot uk"> writes:
    > On 08/08/13 09:24, Jukka Lahtinen wrote:


    >> Value val = map.get(key);
    >> if (val != null // usually false


    > I think (null != val ... ) is better.


    Why? I see no real difference.
    If you are thinking about NullPointerException, it is not thrown by
    this kind of comparison, where you just check equality to null without
    refering any possible members of val.

    --
    Jukka Lahtinen
    Jukka Lahtinen, Aug 8, 2013
    #16
  17. On 8/8/2013 5:07 AM, lipska the kat wrote:
    > On 08/08/13 09:24, Jukka Lahtinen wrote:
    >> Eric Sosman <> writes:
    >>> On 8/7/2013 7:52 PM, Lew wrote:

    >
    > <snip>
    >
    >> Value val = map.get(key);
    >> if (val != null // usually false
    >> || map.containsKey(key)) { // usually false

    >
    > I think (null != val ... ) is better.


    That is a C/C++'ism often used with ==.

    Not so useful in Java due to stricter type check.

    Arne
    Arne Vajhøj, Aug 8, 2013
    #17
  18. Sebastian

    Arne Vajhøj Guest

    On 8/8/2013 10:34 AM, Jukka Lahtinen wrote:
    > lipska the kat <"nospam at neversurrender dot co dot uk"> writes:
    >> On 08/08/13 09:24, Jukka Lahtinen wrote:

    >
    >>> Value val = map.get(key);
    >>> if (val != null // usually false

    >
    >> I think (null != val ... ) is better.

    >
    > Why? I see no real difference.
    > If you are thinking about NullPointerException, it is not thrown by
    > this kind of comparison, where you just check equality to null without
    > refering any possible members of val.


    The trick sometimes called Yoda condition is from C/C++ where
    you could intend to write:
    if(val == null)
    and end up writing:
    if(val = null)
    and not get a compile error but instead a different semantics than
    expected.

    Writing:
    if(null == val)
    avoid that risk as:
    if(null = val)
    will give a compile error.

    But Java is different.

    Arne
    Arne Vajhøj, Aug 8, 2013
    #18
  19. Sebastian

    Stefan Ram Guest

    Kevin McMurtrie <> writes:
    >Most automatic Java profilers are a waste of effort. There are two
    >methods supported by the JVM:


    As a corollary to »Don't try to fix it if it ain't broke¹«
    and »You ain't gonna need it.«:

    Either the completed product will be observably too slow or not.

    If it is /not/ observably too slow,

    any further work into optimization (which usually reduces
    code portability and quality) will be a waste of time.
    (And possibly work already done in this direction so far
    already was a waste of time.)

    If it /is/ observably too slow,

    then, using reasoning and possibly a profiler, one can
    identify possible regions of code eligible to further
    optimization efforts. The beauty of fixing something
    that actually /is/ broken is that it /will be observable/
    whether the modifications make the product faster,
    because we already have asserted that it is observably
    too slow, so it also will be observable when this
    condition is being changed (And possibly work already
    done in this direction before was a waste of time,
    because it was optimization at the wrong places.)

    Of course, one can still choose to write code in the way
    most efficient in the first place, whenever one can see that
    this is /obviously/ (with certainity) the way most efficient,
    and it comes with little additional cost.

    ¹ »ain't broke« = »is not broken«, »is not broken« is more
    common, but I remember it this odd way: »ain't broke«.
    Stefan Ram, Aug 8, 2013
    #19
  20. On 08/08/2013 12:14 AM, Kevin McMurtrie wrote:
    > In article <ktt63o$l57$>,
    > Sebastian <> wrote:
    >
    >> Am 07.08.2013 12:02, schrieb Donkey Hottie:
    >>> 07.08.2013 10:44, Sebastian kirjoitti:
    >>>> @Override
    >>>> public int compare(AttrValue o1, AttrValue o2)
    >>>> {
    >>>> Long ts1 = o1.getEffectiveSequenceNumber(); // ??
    >>>> Long ts2 = o2.getEffectiveSequenceNumber(); // ??
    >>>> return ts1.compareTo(ts2);
    >>>> }
    >>>>
    >>>> Would you expect a measureable impact of creating these
    >>>> variables ts1, ts2, instead of "inlining" the calls to
    >>>> getEffectiveSequenceNumber(). (Using JDK 6?)
    >>>>
    >>>> How can I reason about this things, probably influenced by
    >>>> JIT, without doing actually measurements, say as part of a
    >>>> code inspection?
    >>>>
    >>>> -- Sebastian
    >>>>
    >>>
    >>> What is getEffectiveSequenceNumber() returning?
    >>>
    >>> If Long, there is no way to prevent the creation of a Long.
    >>>
    >>> If long, try and use long variables instead, and manually code the
    >>> comparison code, it's not that complicated anyway.
    >>>

    >>
    >> Thanks for the hint, yes, I forgot to state that the method returns a
    >> long primitive.
    >>
    >> However, your answer does not address my question, which wasn't about
    >> how to code a long comparison.
    >>
    >> -- Sebastian

    >
    > This:
    > Long l= 4L;
    >
    > is shorthand for:
    >
    > Long l= Long.valueOf(4);
    >
    > It's optimized for some values to return a singleton. For others you'll
    > get a performance penalty on Long creation. How big that is depends on
    > your system. Run it a 100 million times and see.
    >
    > Since comparing the primitives is known to be fast and trivial, I'd just
    > compare the primitives. There's no point writing potentially slow code
    > for no good reason.
    >

    This little snippet from 5.1.7 of the language spec requires caching:

    "If the value p being boxed is true, false, a byte, or a char in the
    range \u0000 to \u007f, or an int or short number between -128 and 127
    (inclusive), then let r1 and r2 be the results of any two boxing
    conversions of p. It is always the case that r1 == r2."

    Oddly enough, not for Long, although it's commonly done (as in OpenJDK 7).

    Note that this definition does not prohibit other caching. So if using
    == it's a really good idea to do some testing.

    AHS

    --
    When a true genius appears, you can know him by this sign:
    that all the dunces are in a confederacy against him.
    -- Jonathan Swift
    Arved Sandstrom, Aug 8, 2013
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ajay

    cost of creating threads

    Ajay, Sep 30, 2004, in forum: Python
    Replies:
    5
    Views:
    601
    Bryan Olson
    Oct 5, 2004
  2. 7stud
    Replies:
    11
    Views:
    674
    Dennis Lee Bieber
    Mar 20, 2007
  3. Replies:
    2
    Views:
    325
  4. Ryan Liu
    Replies:
    4
    Views:
    381
    bruce barker
    Jan 20, 2009
  5. News123
    Replies:
    7
    Views:
    372
    Dave Angel
    Jun 29, 2009
Loading...

Share This Page