Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Cost of creating objects?

Reply
Thread Tools

Cost of creating objects?

 
 
Eric Sosman
Guest
Posts: n/a
 
      08-08-2013
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
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
 
 
 
Kevin McMurtrie
Guest
Posts: n/a
 
      08-08-2013
In article <(E-Mail Removed)>,
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.
 
Reply With Quote
 
 
 
 
Kevin McMurtrie
Guest
Posts: n/a
 
      08-08-2013
In article <ktt63o$l57$(E-Mail Removed)>,
Sebastian <(E-Mail Removed)> 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.
 
Reply With Quote
 
Jukka Lahtinen
Guest
Posts: n/a
 
      08-08-2013
Eric Sosman <(E-Mail Removed)> 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
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      08-08-2013
On 8/8/2013 4:24 AM, Jukka Lahtinen wrote:
> Eric Sosman <(E-Mail Removed)> 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
(E-Mail Removed)d
 
Reply With Quote
 
Jukka Lahtinen
Guest
Posts: n/a
 
      08-08-2013
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
 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      08-08-2013
On 8/8/2013 5:07 AM, lipska the kat wrote:
> On 08/08/13 09:24, Jukka Lahtinen wrote:
>> Eric Sosman <(E-Mail Removed)> 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




 
Reply With Quote
 
Arne Vajhj
Guest
Posts: n/a
 
      08-08-2013
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

 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      08-08-2013
Kevin McMurtrie <(E-Mail Removed)> 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.

 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      08-08-2013
On 08/08/2013 12:14 AM, Kevin McMurtrie wrote:
> In article <ktt63o$l57$(E-Mail Removed)>,
> Sebastian <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
creating garbage collectable objects (caching objects) News123 Python 7 06-29-2009 04:12 PM
the most cost effective way to persist page level objects in server Ryan Liu ASP .Net 4 01-20-2009 02:56 AM
the cost of intermediate objects stevecanfield@yahoo.com Java 2 10-10-2007 06:20 AM
class objects, method objects, function objects 7stud Python 11 03-20-2007 06:05 PM
NZ Cost vs US Cost... news.xtra.co.nz NZ Computing 14 01-05-2006 01:03 PM



Advertisments