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

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

Autoboxing and Performance ?

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

Contents

  Autoboxing and Performance ? Peter Olcott <OCR4Screen> - 2013-08-20 05:15 -0500
    Re: Autoboxing and Performance ? Joerg Meier <joergmmeier@arcor.de> - 2013-08-20 12:20 +0200
      Re: Autoboxing and Performance ? Peter Olcott <OCR4Screen> - 2013-08-20 05:33 -0500
        Re: Autoboxing and Performance ? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-08-20 10:43 +0000
          Re: Autoboxing and Performance ? Peter Olcott <OCR4Screen> - 2013-08-20 06:04 -0500
            Re: Autoboxing and Performance ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-20 08:08 -0400
            Re: Autoboxing and Performance ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-20 20:15 -0400
        Re: Autoboxing and Performance ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-20 20:12 -0400
        Re: Autoboxing and Performance ? Sven Köhler <remove-sven.koehler@gmail.com> - 2013-08-21 03:52 +0300
          Re: Autoboxing and Performance ? Sebastian <news@seyweiler.dyndns.org> - 2013-08-21 07:27 +0200
            Re: Autoboxing and Performance ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-21 18:43 -0400
              Re: Autoboxing and Performance ? Sven Köhler <remove-sven.koehler@gmail.com> - 2013-08-22 08:08 +0300
            Re: Autoboxing and Performance ? Sven Köhler <remove-sven.koehler@gmail.com> - 2013-08-22 07:56 +0300
              Re: Autoboxing and Performance ? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-08-22 10:51 -0700
                Re: Autoboxing and Performance ? Martin Gregorie <martin@address-in-sig.invalid> - 2013-08-22 19:36 +0000
                  Re: Autoboxing and Performance ? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-08-22 13:01 -0700
                  Re: Autoboxing and Performance ? Martin Gregorie <martin@address-in-sig.invalid> - 2013-08-22 21:19 +0000
                    Re: Autoboxing and Performance ? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-08-22 14:39 -0700
                      Re: Autoboxing and Performance ? markspace <markspace@nospam.nospam> - 2013-08-22 19:50 -0700
                        Re: Autoboxing and Performance ? Martin Gregorie <martin@address-in-sig.invalid> - 2013-08-23 23:16 +0000
                          Re: Autoboxing and Performance ? Sven Köhler <remove-sven.koehler@gmail.com> - 2013-08-24 17:20 +0300
                    Re: Autoboxing and Performance ? Lew <lewbloch@gmail.com> - 2013-08-23 11:08 -0700
                      Re: Autoboxing and Performance ? Joerg Meier <joergmmeier@arcor.de> - 2013-08-23 22:52 +0200
                        Re: Autoboxing and Performance ? Jim Gibson <jimsgibson@gmail.com> - 2013-08-23 16:38 -0700
                  Re: Autoboxing and Performance ? "John B. Matthews" <nospam@nospam.invalid> - 2013-08-23 06:17 -0400
                    Re: Autoboxing and Performance ? Jeff Higgins <jeff@invalid.invalid> - 2013-08-23 17:25 -0400
                    Re: Autoboxing and Performance ? Jeff Higgins <jeff@invalid.invalid> - 2013-08-25 18:34 -0400
                      Re: Autoboxing and Performance ? Jeff Higgins <jeff@invalid.invalid> - 2013-08-28 10:52 -0400
                  Re: Autoboxing and Performance ? Martin Gregorie <martin@address-in-sig.invalid> - 2013-08-23 23:37 +0000
          Re: Autoboxing and Performance ? Robert Klemme <shortcutter@googlemail.com> - 2013-08-26 19:33 +0200
            Re: Autoboxing and Performance ? Sven Köhler <remove-sven.koehler@gmail.com> - 2013-08-29 10:09 +0300
              Re: Autoboxing and Performance ? Jan Burse <janburse@fastmail.fm> - 2013-08-29 14:14 +0200
        Re: Autoboxing and Performance ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-08-29 21:28 -0300
    Re: Autoboxing and Performance ? Jan Burse <janburse@fastmail.fm> - 2013-08-20 20:03 +0200
      Re: Autoboxing and Performance ? Lew <lewbloch@gmail.com> - 2013-08-20 16:23 -0700
        Re: Autoboxing and Performance ? Jan Burse <janburse@fastmail.fm> - 2013-08-21 11:51 +0200
          Re: Autoboxing and Performance ? Lew <lewbloch@gmail.com> - 2013-08-21 08:39 -0700
            Re: Autoboxing and Performance ? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-08-21 16:51 +0100
          Re: Autoboxing and Performance ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-21 19:19 -0400
            Re: Autoboxing and Performance ? Jan Burse <janburse@fastmail.fm> - 2013-08-22 09:49 +0200
      Re: Autoboxing and Performance ? Jan Burse <janburse@fastmail.fm> - 2013-08-21 11:54 +0200
    Re: Autoboxing and Performance ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-20 20:06 -0400
      Re: Autoboxing and Performance ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-20 21:19 -0400
        Re: Autoboxing and Performance ? Joerg Meier <joergmmeier@arcor.de> - 2013-08-21 10:05 +0200
          Re: Autoboxing and Performance ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-21 07:19 -0400
            Re: Autoboxing and Performance ? Joerg Meier <joergmmeier@arcor.de> - 2013-08-22 00:18 +0200
              Re: Autoboxing and Performance ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-21 19:58 -0400
          Re: Autoboxing and Performance ? Lew <lewbloch@gmail.com> - 2013-08-21 08:36 -0700
        Re: Autoboxing and Performance ? taqmcg@gmail.com - 2013-08-21 09:37 -0700
    Re: Autoboxing and Performance ? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-08-20 23:28 -0500
    Re: Autoboxing and Performance ? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-08-21 10:09 +0100
      Re: Autoboxing and Performance ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-21 19:04 -0400
        Re: Autoboxing and Performance ? Arivald <NOSPAMarivald@interia.pl> - 2013-08-22 07:39 +0200
    Re: Autoboxing and Performance ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-08-29 01:42 -0300

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#25133

Am 24.08.2013 02:16, schrieb Martin Gregorie:
> In my book that's algebraic manipulation, i.e. mathematics, not physics. 
> Physics purports to describe the real world and hence any measurement 
> must specify the units, while algebra is dimensionless.

Yes, but the (rather philosophical and not very fruitful) point that
Stefan was trying to make is, that only the description of something
(here: the measurement of a distance) requires a unit, and that the
thing being described (here: the distance) doesn't actually have a unit.
Example: The distance between earth and sun can be described either in
meters or in inch.

And yes, in many cases make sense to describe something without having a
unit and things become meaningless without a unit.


Regards,
  Sven

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

#25126

Martin Gregorie wrote:
> Stefan Ram wrote:
>>   Moreover, a lenght (in physics) /does not have/ a unit!
>>
> 
> As a chemistry graduate I disagree quite strongly with that. Its quite 
> impossible to calculate anything without knowing the units the givens 
> were measured in. I seem to recall a certain NASA Mars probe failing 
> because the units used to measure fuel remaining were unstated. As a 
> result somebody calculated burns wrongly by confusing lbs and kg, causing 
> the probe to run out of fuel and miss Mars entirely.

If read carefully, he didn't say the unit shouldn't be known, only that that knowledge 
should be prior to run-time.
 
A certain Mars probe would have landed if that unit were properly communicated by 
memo. It need not have been encoded in the computer.

You are correct that the problem was that the unit was unstated. That is not at issue. 
What is at issue is where that statement should be made.

>>   For example, there is a certain distance from the sun to the Procyon,
>>   what is the unit of that lenght? As a physical value, it has no unit!
>>   Only when one wants to write it down, one has to choose a certain unit
>>   system and number system, and one can choose every unit system one
>>   likes. This is an artefact of our notation, not a property of the
>>   length.
>>
> 
> If you don't know the units the measurement was made in, its a 
> meaningless number that can't be used to calculate a valid result any 

Again, it is not in dispute that the unit is needed for communication. 

> more than you can add "not very far" to "a huge distance" and get a 
> measurable distance.

And yet again, measurement of a distance does require a unit. It is distance 
itself that does not.

I didn't read any post here that attempts to refute the necessity of units for 
calculation and communication.

I do read two positions, one that the unit should be communicated out of band 
and the other that it should be encoded in the software.

Like all engineering decisions, the choice depends on the need of the system at 
hand. Each has features that render it more optimal for some scenarios and less 
for others.

-- 
Lew

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

#25127

On Fri, 23 Aug 2013 11:08:00 -0700 (PDT), Lew wrote:

> A certain Mars probe would have landed if that unit were properly communicated by 
> memo. It need not have been encoded in the computer.

> You are correct that the problem was that the unit was unstated. That is not at issue. 
> What is at issue is where that statement should be made.

I would argue the other way around: the problem wasn't that the unit was
unstated, which would be perfectly fine, the problem was that someone used
a number that had no unit stated and didn't bother to find out what unit it
was. If you use X, you don't get to say "Oh, nobody told me Y about it".
It's your job to find out about X if you want to use it.

That being said, it seems to me that whoever thought it would be alright to
use imperial units in a Mars rover should be immediately fired for poor
judgement.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

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

#25131

In article <7ud24v7thir5.1fbfrgyz5jy5n$.dlg@40tude.net>, Joerg Meier
<joergmmeier@arcor.de> wrote:

> On Fri, 23 Aug 2013 11:08:00 -0700 (PDT), Lew wrote:
> 
> > A certain Mars probe would have landed if that unit were properly
> > communicated by 
> > memo. It need not have been encoded in the computer.
> 
> > You are correct that the problem was that the unit was unstated. That is
> > not at issue. 
> > What is at issue is where that statement should be made.

In the case of the Mars Climate Orbiter, apparently, the unit (newton)
was stated in the contract, but ignored by the contractor, who used
pound-force instead:

<http://en.wikipedia.org/wiki/Mars_Climate_Orbiter>

> I would argue the other way around: the problem wasn't that the unit was
> unstated, which would be perfectly fine, the problem was that someone used
> a number that had no unit stated and didn't bother to find out what unit it
> was. If you use X, you don't get to say "Oh, nobody told me Y about it".
> It's your job to find out about X if you want to use it.
> 
> That being said, it seems to me that whoever thought it would be alright to
> use imperial units in a Mars rover should be immediately fired for poor
> judgement.

Well, it wasn't a rover, and it wasn't supposed to land, but go into
orbit. Because of the units mix up, it went too low during its first
pass around the planet and broke up in the atmosphere (supposedly,
since it was on the back side of the planet when it happened.)

-- 
Jim Gibson

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

#25123

In article <dimensions-20130823034713@ram.dialup.fu-berlin.de>,
 ram@zedat.fu-berlin.de (Stefan Ram) wrote:

>  Okay, maybe the proponents of »units« in this newsgroup
>  actually want dimensions!

For reference, JScience [1] has a useful implementation of 
Units of Measurement [2], formerly JSR-275 [3]. The package 
org.jscience.physics.amount includes examples of dimension 
checking [4].

[1] <http://jscience.org/>
[2] <http://www.unitsofmeasurement.org/>
[3] <http://www.jcp.org/en/jsr/detail?id=275>
[4] <http://jscience.org/api/org/jscience/physics/amount/package-summary.html>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

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

#25128

On 08/23/2013 06:17 AM, John B. Matthews wrote:
> In article <dimensions-20130823034713@ram.dialup.fu-berlin.de>,
>   ram@zedat.fu-berlin.de (Stefan Ram) wrote:
>
>>   Okay, maybe the proponents of »units« in this newsgroup
>>   actually want dimensions!
>
> For reference, JScience [1] has a useful implementation of
> Units of Measurement [2], formerly JSR-275 [3]. The package
> org.jscience.physics.amount includes examples of dimension
> checking [4].
>
> [1] <http://jscience.org/>
> [2] <http://www.unitsofmeasurement.org/>
> [3] <http://www.jcp.org/en/jsr/detail?id=275>
> [4] <http://jscience.org/api/org/jscience/physics/amount/package-summary.html>
>
I'll drop a link here for my own memento.
Units Dimensions and Dimensionless Numbers - Ipsen
http://archive.org/details/unitsdimensionsa032710mbp

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

#25134

On 08/23/2013 06:17 AM, John B. Matthews wrote:
> In article <dimensions-20130823034713@ram.dialup.fu-berlin.de>,
>   ram@zedat.fu-berlin.de (Stefan Ram) wrote:
>
>>   Okay, maybe the proponents of »units« in this newsgroup
>>   actually want dimensions!
>
> For reference, JScience [1] has a useful implementation of
> Units of Measurement [2], formerly JSR-275 [3]. The package
> org.jscience.physics.amount includes examples of dimension
> checking [4].
>
> [1] <http://jscience.org/>
> [2] <http://www.unitsofmeasurement.org/>
> [3] <http://www.jcp.org/en/jsr/detail?id=275>
> [4] <http://jscience.org/api/org/jscience/physics/amount/package-summary.html>
>
Thanks for the reminder.
Javolution library Version 6 released earlier this month is a drastic 
change from the earlier versions that JScience library depends on.
Work on JScience Version 5 seems to underway. A look at the source 
repository reveals that the org/jscience/physics/amount package will be 
replaced with a new org/jscience/physics/dimension and unit packages.
<https://java.net/projects/jscience/sources/svn/show>

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

#25162

On 08/27/2013 07:16 PM, Stefan Ram wrote:
> Jeff Higgins <jeff@invalid.invalid> writes:
>> change from the earlier versions that JScience library depends on.
>
>    According to the World-Wide Web a person named »Jeff« has written
>    a Groovy category that uses JScience to support things like

Some years ago a local newspaper reported that Jeffrey (Middle name 
different from mine) Higgins had been arrested the previous evening in 
connection with the armed robbery of a local convenience store. The 
article provided some coworkers considerable fun.

> def len = 2.kilometers + 500.meters
>
>    . (He carefully avoided using »1« to avoid showing what I fear
>    would be »1.meters« instead of »1.meter«.)

It seems to me that TextFormat should be able to handle that, not sure, 
but I seem to remember something about it. I'm not very familiar with 
Groovy at all.

JScience 4.3.1 is entirely usable but it seems version 5 still has a 
ways to go. I've begun investigating the Eclipse UOMo. I'll be 
interested to see how JSR 354 pans out. It's kinda shame that all of 
these APIs don't have a common core available for instance arithmetic, 
text formatting, XML serialization, etc.

>
>    (This post might still be on-topic with regard to the subject
>    insofar as the above Groovy notation might be read to include
>    some kind of »autoboxing«.)
>

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

#25130

On Fri, 23 Aug 2013 01:58:02 +0000, Stefan Ram wrote:

>   When every physical value has a dimension at runtime, this indeed even
>   helps to avoid errors, for example, to avoid adding a lenght and an
>   angle.
>
That's a different issue. Quite simply, any equation that adds a length 
to an angle is INVALID and any paper that included such an equation 
should fail peer review and be rejected.

There is a method for detecting that type of error that's taught in first 
year university physics and chemistry classes: its called "dimensional 
analysis". Example of a bogus equation, which will be meaningful for all 
you long-time SF fans out there: the Blackett-Dirac equation at the heart 
of James Blish's "Cities in Flight" novels fails dimensional analysis, so 
a spindizzy can never work. Unfortunately.

Coming back on topic, computer programs are far more likely to be 
calculating with measured quantities and so will need to know the units 
used to take each measurement than they are to be doing dimensional 
analysis. Hence, any object that represents a measurement should, for 
strict OO conformance, contain both the numeric value and the units with 
which the measuring instrument is calibrated as well as a method to 
convert measurements in any appropriate unit to another. 
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#25142

On 08/21/2013 02:52 AM, Sven Köhler wrote:

> That said, I seriously think that all the wrapper classes were just
> intended for what the name suggests: wrapping a primitive type when you
> really need an Object. And most of the time you don't need an object.

I tend to agree.  But that totally depends on the type of applications 
you are dealing with.

Just as a data point: object types are not necessarily that expensive. 
I once wrote a hash map with int as key type (basically copying 
java.util.HashMap) just to find out that the performance difference to a 
standard HashMap with Integer as keys was negligible.  (I don't remember 
all the details but I believe I also used values outside the cached range.)

> I'd even call program is seriously broken if it uses Integer where int
> could be used. I was never in need of a mutable Integer.

Then you probably never used reflection.  Which is another good reason 
to have java.lang.Integer and the like.

Cheers

	robert

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

#25166

Am 26.08.2013 20:33, schrieb Robert Klemme:
>> I'd even call program is seriously broken if it uses Integer where int
>> could be used. I was never in need of a mutable Integer.
> 
> Then you probably never used reflection.  Which is another good reason
> to have java.lang.Integer and the like.

Now reflection doesn't allow you to use int instead of Integer, right?
Mostly because the arguments have to be passed as an array of Objects,
if I remember correctly. So int can't be used, right?


Regards,
  Sven

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

#25168

Sven Köhler schrieb:
> Am 26.08.2013 20:33, schrieb Robert Klemme:
>>> I'd even call program is seriously broken if it uses Integer where int
>>> could be used. I was never in need of a mutable Integer.
>>
>> Then you probably never used reflection.  Which is another good reason
>> to have java.lang.Integer and the like.
>
> Now reflection doesn't allow you to use int instead of Integer, right?
> Mostly because the arguments have to be passed as an array of Objects,
> if I remember correctly. So int can't be used, right?
>
>
> Regards,
>    Sven
>

It depends what part of the reflection API your
are using. Yes for example Method.invoke awaits
an Object array. On the other hand there is a
Field.getInt and Field.setInt.

Bye

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

#25173

On 08/20/2013 07:33 AM, Peter Olcott wrote:
> On 8/20/2013 5:20 AM, Joerg Meier wrote:
>> On Tue, 20 Aug 2013 05:15:30 -0500, Peter Olcott wrote:
>>
>>>   From Java A Beginner's Guide, Fifth Edition by Herbert Schildt,
>>> page 425:
>>
>>> class AutoBox3 {
>>>     public static void main(String args[]) {
>>>     Integer iOb;
>>>     iOb = 99;
>>
>>> // The following automatically unboxes iOb,
>>> // performs the increment, and then reboxes
>>> // the result back into iOb
>>> ++iOb;
>>
>>> It seems to me that all this unboxing and reboxing is a complete waste
>>> of CPU time. It would make much more sense to provide an
>>> Integer.Increment() member function that directly operates on the
>>> contained data.
>>
>>> Why does Java waste so much CPU resources with its unboxing and reboxing
>>> in cases such as this, and not simply provide member functions that
>>> directly operate on the contained data?
>>
>> Because IntegerS and other Number classes are immutable. The contained
>> data
>> is not allowed to be changed under any circumstances.
>>
>> Liebe Gruesse,
>>         Joerg
>>
>
> So the original object is replaced with a new object?
>
> What is the benefit (of immutability) that is worth the cost of this
> poor performance?

Not being facetious here. Just Google on immutability.

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]

#25070

Peter Olcott schrieb:
> It seems to me that all this unboxing and reboxing is a complete waste
> of CPU time. It would make much more sense to provide an
> Integer.Increment() member function that directly operates on the
> contained data.

Most probably the generated code for unboxing/boxing will
use Integer.intValue() to access the value and Integer.valueOf()
to create a new object.

Now Integer.valueOf() has a threshold, below this threshold
not a new object is created but an object is fetched from a
cache. Usually the threshold is 128.

In your present case thus, already for 99 an object from the
cache is fetched, and then for 100 also an object from the cache
is fetched, thus not involving any single heap allocation.

The heap allocation happens once when the Integer class
allocates its cache. Bottom line is that for values below
the threashold unboxing/boxing incures a low overhead.

The caching is possible because the Integer class is immutable.
Therefore a cached object can be returned. If the Integer class
were mutable, a cached object could not be returned, since the
client code could modify it.

Bye

P.S.: Here is the JDK 1.7.25 source code of Integer.valueOf:

    /**
      * Returns an {@code Integer} instance representing the specified
      * {@code int} value.  If a new {@code Integer} instance is not
      * required, this method should generally be used in preference to
      * the constructor {@link #Integer(int)}, as this method is likely
      * to yield significantly better space and time performance by
      * caching frequently requested values.
      *
      * This method will always cache values in the range -128 to 127,
      * inclusive, and may cache other values outside of this range.
      *
      * @param  i an {@code int} value.
      * @return an {@code Integer} instance representing {@code i}.
      * @since  1.5
      */
     public static Integer valueOf(int i) {
         assert IntegerCache.high >= 127;
         if (i >= IntegerCache.low && i <= IntegerCache.high)
             return IntegerCache.cache[i + (-IntegerCache.low)];
         return new Integer(i);
     }

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

#25072

Jan Burse wrote:
> Peter Olcott schrieb:
>> It seems to me that all this unboxing and reboxing is a complete waste

It "seems" to you based on what evidence and measurements?

>> of CPU time. It would make much more sense to provide an

Based on what evidence? By what criteria of "more sense"? What about what is sacrificed?

>> Integer.Increment() member function that directly operates on the
>> contained data.

That's what primitives are for.

> Most probably the generated code for unboxing/boxing will
> use Integer.intValue() to access the value and Integer.valueOf()
> to create a new object.

Assuming HotSpot doesn't entirely optimize away the object references.

> Now Integer.valueOf() has a threshold, below this threshold
> not a new object is created but an object is fetched from a
> cache. Usually the threshold is 128.
> 
> In your present case thus, already for 99 an object from the
> cache is fetched, and then for 100 also an object from the cache
> is fetched, thus not involving any single heap allocation.
> 
> The heap allocation happens once when the Integer class
> allocates its cache. Bottom line is that for values below
> the threashold unboxing/boxing incures a low overhead.
> 
> The caching is possible because the Integer class is immutable.
> Therefore a cached object can be returned. If the Integer class
> were mutable, a cached object could not be returned, since the
> client code could modify it.

It is very dangerous to make performance claims about Java based on 
_a priori_ reasoning. Under what load? What percentage of code is subject to 
autoboxing? (It should be zero, BTW.) With or without HotSpot optimization?

It's not limited to wrapper types. Any object might be moved off the heap and 
enregistered, even, if HotSpot so decides and can do it.

If *actual measurement* reveals a problem *in real code*, then don't use the 
wrapper types at all in those sections of code. Why would you?

-- 
Lew

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

#25088

Lew schrieb:
> [ bla bla ]

I don't care what you posted Lew. Its totally off topic
to what I posted. And it is just some misanthrope shitload.

Bye

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

#25093

Jan Burse wrote:
> Lew schrieb:
> 
> > [ bla bla ]
> 
> 
> 
> I don't care what you posted Lew. Its totally off topic

Not true. I don't know why you have this bug up your butt.

> to what I posted. And it is just some misanthrope shitload.

It was relevant and you saying otherwise doesn't change that. 

And how does a comment that says nothing about people, let alone
anything negative, rate as "misanthrope [sic]"?

A person asked about an effect of a Java idiom on performance. 
I pointed out that performance is only an issue if evidence and 
measurement, controlled for relevant factors, indicate an issue.

How is that off topic, troll?

-- 
Lew

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

#25094

On 21/08/13 16:39, Lew wrote:
> Jan Burse wrote:
>> Lew schrieb:
>>
>>> [ bla bla ]
>>
>>
>>
>> I don't care what you posted Lew. Its totally off topic
>
> Not true. I don't know why you have this bug up your butt.
>
>> to what I posted. And it is just some misanthrope shitload.
>
> It was relevant and you saying otherwise doesn't change that.
>
> And how does a comment that says nothing about people, let alone
> anything negative, rate as "misanthrope [sic]"?
>
> A person asked about an effect of a Java idiom on performance.
> I pointed out that performance is only an issue if evidence and
> measurement, controlled for relevant factors, indicate an issue.
>
> How is that off topic, troll?

Anyone who doesn't agree with you is a troll according to you Bloch

get over yourself


-- 
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]

#25099

On 8/21/2013 5:51 AM, Jan Burse wrote:
> Lew schrieb:
>> [ bla bla ]
>
> I don't care what you posted Lew.

You replied to it.

>                                     Its totally off topic
> to what I posted.

????

He made some comments to OP that directly addressed
OP's interest in the performance.

Very relevant.

He made some comments to you that explained that you
you had forgotten about the escape analysis
capability in your explanation.

Very relevant.

Arne

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

#25105

Arne Vajhøj schrieb:
> He made some comments to you that explained that you
> you had forgotten about the escape analysis
> capability in your explanation.

It seems to me that Lew has sometimes no clue what he is
writing about. For example I wrote:

> Most probably the generated code for unboxing/boxing will
> use Integer.intValue() to access the value and Integer.valueOf()
> to create a new object.

Which refers to Java byte code generation.

Then Lew wrote:

 > Assuming HotSpot doesn't entirely optimize away the object references.

Which refers to code generate by the JVM from the
given Java byte code. So I didn't say something wrong.

Then Lew wrote:

 > It is very dangerous to make performance claims about
 > Java based on _a priori_ reasoning.

I could ask him the same about his Hotspot escape analysis
claim. Where is HIS evidence? Under what load? What percentage
of code is subject to the Hotspot escape analysis? Etc..

Since the OPs code is main() and not some heavily used
loop, most likely no Hotspot compilation will kick in at
all. So most likely the code will be executed as I
described it:

> In your present case thus, already for 99 an object from the
> cache is fetched, and then for 100 also an object from the cache
> is fetched, thus not involving any single heap allocation.

I am willingly to retract my claim if some counter evidence
can be provided.

Bye

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web