wood burning stoves 2.0*
The moose likes Java in General and the fly likes To authors Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "To authors" Watch "To authors" New topic
Author

To authors

Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8904

Hi Cay,

I am great fan of yours. I liked you book on Java 2.

Could you please tell us what are features to avoid in Java 5. I am talking about things which could cause performance problems.


Groovy
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
Cay, might you also discuss about the potential threats, might be not just performance, but also the memory allocations in JVM, resource consumption, Garbage collection, etc.

Nick


SCJP 1.2, OCP 9i DBA, SCWCD 1.3, SCJP 1.4 (SAI), SCJD 1.4, SCWCD 1.4 (Beta), ICED (IBM 287, IBM 484, IBM 486), SCMAD 1.0 (Beta), SCBCD 1.3, ICSD (IBM 288), ICDBA (IBM 700, IBM 701), SCDJWS, ICSD (IBM 348), OCP 10g DBA (Beta), SCJP 5.0 (Beta), SCJA 1.0 (Beta), MCP(70-270), SCBCD 5.0 (Beta), SCJP 6.0, SCEA for JEE5 (in progress)
Cay Horstmann
author
Ranch Hand

Joined: Nov 14, 2004
Posts: 114
    
  10
If we take Java 1.4 as a baseline, there aren't many Java 5 issues that cause performance problems.

Generics and the "for each" loop basically do what you would have done by hand. As long as you realize that there is no free lunch, you won't be surprised. (For example, when you get an element from an ArrayList<String>, there is a runtime "instanceof" check, just as if you had used a cast.)

Multithreading has interesting changes. Generally, using the new locks and condition variables should give you performance that is at least as good as using "synchronized", and often better. One of the things to watch out for is "fairness". Fair locking sounds good, but it is really quite expensive, and almost never necessary.

Some people have groused about the performance of autoboxing. Sure, it does a bunch of things behind your back, and you really don't want to replace an int[] array with an ArrayList<Integer>. But I find that pretty academic--outside a second-semester college course, who collects integers in an array list anyway?

I'd like to know the kind of performance problems that other people run into. I've been very happy with 5.0 performance overall, both for client and server applications.

Cheers,

Cay


Author of Java 8 for the Really Impatient
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
Cay,


Generally, using the new locks and condition variables should give you performance that is at least as good as using "synchronized", and often better.

I would like to know which locking algorithm in fact Tiger is using?

Nick
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8904

Talking about auto(un)boxing, wouldn't code like



cause performace problems.

I could have written the above as

which avoids creation of extra Integer object.

Please let me your comments cay. Thanks
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
Taking about the autoboxing, Pradeep raises an interesting question.

I would like to know, if the 2nd case happen, how the compiler transform it? Will it perform Integer i = k; i++; by converting the Integer object to int, do the i++, and then convert the result back to Integer object? If so, that's really a problem.

Nick
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8904

I would like to know, if the 2nd case happen, how the compiler transform it? Will it perform Integer i = k; i++; by converting the Integer object to int, do the i++, and then convert the result back to Integer object? If so, that's really a problem


That is how it works.
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
That is how it works.



Thus, in other sense, for those *syntax*, it just ONLY help us to simply the coding effort, but the compiler will still transform them back to the old day Java codes.

But, Tiger really without any improvement in this area?

Nick
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8904

Cay,

Generics is a huge topic. is there any plan to write a book on Genrics? That would be quite useful to us.

Thanks
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8904

Originally posted by Nicholas Cheung:



Thus, in other sense, for those *syntax*, it just ONLY help us to simply the coding effort, but the compiler will still transform them back to the old day Java codes.

But, Tiger really without any improvement in this area?

Nick



Tiger caches (creates only once)some Integer Objects i.e. from -128 to 127.


Integer i= 127;
Integer i1 = 127;

i1==1 return true. If 127 above were replaced by say 300, then i1==i will be false.
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982

Tiger caches (creates only once)some Integer Objects i.e. from -128 to 127.

How about other Wrapper objects? JVM will do this for them as well?

But if Tiger just cached for such a *small* range of objects, what is the purpose of? Seems not really help if we need some numbers greater than 127 or less than -128.

Nick
[ November 17, 2004: Message edited by: Nicholas Cheung ]
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8904

How about other Wrapper objects? JVM will do this for them as well?


For Boolean true and false is cached. The range -128 to +127 applies to Short,Byte and Long. Character,Float etc have their own ranges.
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982

For Boolean true and false is cached. The range -128 to +127 applies to Short,Byte and Long. Character,Float etc have their own ranges.

But what is the intention for doing this? Does this really helpful?

Nick
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8904

Originally posted by Nicholas Cheung:

But what is the intention for doing this? Does this really helpful?

Nick


If your code is using the values in the range then the objects are not created again. Performance gain but only for the values in the range.
[ November 17, 2004: Message edited by: Pradeep Bhat ]
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982

If your code is using the values in the range then the objects are not created again. Performance gain but only for the values in the range.

Unless those numbers are constants and unique, otherwise, it is of a low probability that it can be reused, like a/c number will have a high chance to be unique, and be within the given range.

Nick
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8904

Interesting thread discussed in theserverside.com site
http://www.theserverside.com/news/thread.tss?thread_id=27129
Cay Horstmann
author
Ranch Hand

Joined: Nov 14, 2004
Posts: 114
    
  10
There has been a lot of discussion about the inefficiency of autoboxing.

Let's put this in perspective. When do you use autoboxing? Only in three circumstances.

1) You are a college student, and your instructor makes you work with an ArrayList<Integer> or another collection of numbers. Efficiency is the least of your worries.

2) Very rarely, you may actually have a small collection of integers, such as the Hashtable<Integer, Component> that is used for JSlider. Let's not get excited about the inefficiency of int/Integer conversion if the table has a handful of entries that probably never change. If you have large collections of int or double, you should use an int[] or double[] array anyway.

3) When you use varargs method (e.g in reflection or MessageFormat), autoboxing is really quite handy. But then autoboxing only automates what you would have programmed by hand anyway.

Let's not get excited about the fact that



does crazy things. Nobody would write code like that anyway.

Ideally, the distinction between int and Integer should totally invisible. With today's JIT technology, it could be left to the optimizer whether to use primitives or objects. Unfortunately, Java boxed itself in (no pun intended) with some poor decisions, such as the behavior of ==/!= for Integer objects, so we'll probably have to wait for the next language after Java to do this right.

Cheers,

Cay
Vedhas Pitkar
Ranch Hand

Joined: Jan 27, 2001
Posts: 445
Originally posted by Cay Horstmann:

Let's put this in perspective. When do you use autoboxing? Only in three circumstances.



I beg to differ,Cay.Because if a feature such as Autoboxing (Rempoval of casts)is present in a language,almost everyone will use it.
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982

I beg to differ,Cay.Because if a feature such as Autoboxing (Rempoval of casts)is present in a language,almost everyone will use it.

I agree with Vedhas. Just when some features are exist, people are intended to use it. Some might just find this feature is very convenient because in the past, we need to first creating a Wrapper and converting it back to primitive.

Nick
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8904

Originally posted by Nicholas Cheung:

I agree with Vedhas. Just when some features are exist, people are intended to use it. Some might just find this feature is very convenient because in the past, we need to first creating a Wrapper and converting it back to primitive.

Nick


I would avoid using auto (un)boxing in my code.
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
I would avoid using auto (un)boxing in my code.

I would do so as well, however, not everyone will do the same.

Nick
Vedhas Pitkar
Ranch Hand

Joined: Jan 27, 2001
Posts: 445
Sorry guys,
I would use autoboxing in my code.
Michael Moser
Greenhorn

Joined: May 14, 2004
Posts: 28
Seems to me there are some pretty compelling arguments to not use autoboxing outlined here. Why do you say you would use it?
Cay Horstmann
author
Ranch Hand

Joined: Nov 14, 2004
Posts: 114
    
  10
Whoa! Let's take a step back here. The first question is: When do you use Integer and Double wrappers?

Look into your code. Calling Integer.parseInt doesn't count--that's a static method. Where do you have new Integer(anInt) or anInteger.intValue()? Only when you put numbers into collections, or when you use methods such as MessageFormat.format or Method.invoke.

How often do you do that? Not often, I bet. (Unless you take a college course in data structures.)

Now here is the horrible truth about autoboxing. Every time that you use autoboxing in this context, your code will run exactly as slowly as it did before JDK 5.0, when you called new Integer/intValue explicitly.

Cheers,

Cay
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: To authors
 
Similar Threads
Could anyone tell me What's JC?
compiling servlet
java sms
"Number Of Objects in Heap"
Radio Button