Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #24908 > unrolled thread

Cost of creating objects?

Back to article view | Back to comp.lang.java.programmer

Contents

  Cost of creating objects? Sebastian <news@seyweiler.dyndns.org> - 2013-08-07 09:44 +0200
    Re: Cost of creating objects? Donkey Hottie <donkey@fredriksson.dy.fi> - 2013-08-07 13:02 +0300
      Re: Cost of creating objects? Sebastian <news@seyweiler.dyndns.org> - 2013-08-07 12:05 +0200
        Re: Cost of creating objects? Donkey Hottie <donkey@fredriksson.dy.fi> - 2013-08-07 14:08 +0300
        Re: Cost of creating objects? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-07 08:08 -0400
        Re: Cost of creating objects? Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-08-07 20:14 -0700
          Re: Cost of creating objects? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-08-08 17:17 -0300
    Re: Cost of creating objects? Joerg Meier <joergmmeier@arcor.de> - 2013-08-07 12:37 +0200
    Re: Cost of creating objects? Sebastian <news@seyweiler.dyndns.org> - 2013-08-07 19:51 +0200
      Re: Cost of creating objects? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-07 15:51 -0400
        Re: Cost of creating objects? Lew <lewbloch@gmail.com> - 2013-08-07 16:52 -0700
          Re: Cost of creating objects? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-07 20:51 -0400
            Re: Cost of creating objects? Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2013-08-08 11:24 +0300
              Re: Cost of creating objects? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-08-08 10:07 +0100
                Re: Cost of creating objects? Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2013-08-08 17:34 +0300
                  Re: Cost of creating objects? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-08 10:42 -0400
                    Re: Cost of creating objects? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-08-08 20:45 +0100
                Re: Cost of creating objects? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-08 10:38 -0400
              Re: Cost of creating objects? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-08 10:13 -0400
      Re: Cost of creating objects? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-07 20:28 -0400
        Re: Cost of creating objects? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-08-08 17:34 -0300
    Re: Cost of creating objects? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-08-07 19:19 +0100
      Re: Cost of creating objects? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-08-07 19:24 +0100
      Re: Cost of creating objects? Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-08-07 20:03 -0700
        Re: Cost of creating objects? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-08-08 17:39 -0300
    Re: Cost of creating objects? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-07 20:24 -0400

Page 1 of 2  [1] 2  Next page →

#24908 — Cost of creating objects?

@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

[toc] | [next] | [standalone]

#24909

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.

-- 

Try to value useful qualities in one who loves you.

[toc] | [prev] | [next] | [standalone]

#24910

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

[toc] | [prev] | [next] | [standalone]

#24912

07.08.2013 13:05, Sebastian kirjoitti:
> 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
> 
> 

if (ts1 < ts2)
    return -1;
else if (ts1 > ts2)
    return 1;
return 0;


-- 

A day for firm decisions!!!!!  Or is it?

[toc] | [prev] | [next] | [standalone]

#24913

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
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24925

In article <ktt63o$l57$1@news.albasani.net>,
 Sebastian <news@seyweiler.dyndns.org> 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.

[toc] | [prev] | [next] | [standalone]

#24937

On 08/08/2013 12:14 AM, Kevin McMurtrie wrote:
> In article <ktt63o$l57$1@news.albasani.net>,
>   Sebastian <news@seyweiler.dyndns.org> 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

[toc] | [prev] | [next] | [standalone]

#24911

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.

[toc] | [prev] | [next] | [standalone]

#24915

Am 07.08.2013 17:39, schrieb Stefan Ram:
> Sebastian<news@seyweiler.dyndns.org>  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

[toc] | [prev] | [next] | [standalone]

#24918

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
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24920

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

[toc] | [prev] | [next] | [standalone]

#24923

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
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24926

Eric Sosman <esosman@comcast-dot-net.invalid> 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

[toc] | [prev] | [next] | [standalone]

#24927

On 08/08/13 09:24, Jukka Lahtinen wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> 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.

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#24931

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

[toc] | [prev] | [next] | [standalone]

#24933

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

[toc] | [prev] | [next] | [standalone]

#24935

On 08/08/13 15:42, Arne Vajhøj wrote:
> 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.

It is, damn that C

lipska


-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun
GNU/Linux user #560883 - http://www.linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#24932

On 8/8/2013 5:07 AM, lipska the kat wrote:
> On 08/08/13 09:24, Jukka Lahtinen wrote:
>> Eric Sosman <esosman@comcast-dot-net.invalid> 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

[toc] | [prev] | [next] | [standalone]

#24930

On 8/8/2013 4:24 AM, Jukka Lahtinen wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> 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
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24922

On 8/7/2013 1:51 PM, Sebastian wrote:
> Am 07.08.2013 17:39, schrieb Stefan Ram:
>> Sebastian<news@seyweiler.dyndns.org>  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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web