Please tell us where you read that, in case we want to assess the sources ourselves.Tan Quang wrote:I read some articles . . .
Did they say how much performance improvement you can expect? I would expect at most a few nanoseconds for each field access, which falls into my definition of imperceptible and negligible. Did they say that performance should be your lowest priority? Did they say that correct design is much more important?converting fields into local variables will help improve performance . . .
Your comment is incorrect. You are not converting anything, but creating an “alias”, which is a second reference to an object already referenced elsewhere. That is usually at best dubious design because changes in one place are reflected in the other place.. . . // convert field to local variable
Because of incorrect design of that class. I think correct design for fields includes initialising them before use,. . . // why if re-assign local variable to field here, we will receive 3 "null" of 3 println below?
Please don't use /** documentation comments */ in that sort of context. Please remind yourself of the different between an object and a reference to is.. . .
/**
* Now, if you change anything in local variable will also cause the field to change
**/
. . .
Performance should be your last consideration; behaviour of the program is what matters. Also remember that the JVM can monitor code for performance problems and can optimise many of those problems, but attempts to be too clever can prevent such optimisations.. . . However, do really should re-assign local variable for field? Does it affect performance?
None. Follow Paul's rule of thumb. Decide whether a variable will be needed by several methods. Decide whether it will be needed outwith the object. If so, it will have to be a field. If you aren't sure, make it a local variable. If you get access problems, change it to a field. You usually use Eclipse and Eclipse has an option to correct compiler errors by converting a local variable to a field.Which cases should convert field into local variable? . . .
Campbell Ritchie wrote:Please don't use /** documentation comments */ in that sort of context. Please remind yourself of the different between an object and a reference to is.
Carey Brown wrote:
The original data is never modified, added to, or deleted. The only purpose it serves is to have its values copied (if applicable) to newMall.Tan Quang wrote: will return the original of the mall, i.e. if I add, delete, or modify its data (KEY, VALUE) it will replace the data and cannot be restored initial data until I restart the server. That's why I have to clone that data before making any modifications.
Paul Clapham wrote:Variables which contain primitive values like int and long, that's different.
Paul Clapham wrote:As for your other question, you should be asking the person who gave you this advice. It's totally wrong to ask somebody who hasn't even read the actual articles, but has only seen a possibly flawed interpretation of them. Anyway if there is any performance improvement to be had by doing that, it's not the sort of thing that I would spend any time considering. The best performance-improving change I could do to the code I'm working with now would be to buy a faster disk to speed up the database access. (Which I do plan to do.) We're talking about seconds of time reduction there, not nanoseconds.
Somebody is using poor nomenclature; “class fields” usually means static fields. That link seems to be as much about performance as anything else, and as I said earlier, the likely difference will be too small to notice.Tan Quang wrote:. . . Local variables or class fields? . . .
That sounds very confused, and I think you have misunderstood something. A getXXX() method should never change anything.Any change on the local variable will lead to changes on getter / field.
Stephan van Hulst wrote:. . . the benchmark in the StackOverflow topic that you linked to is poorly written. . . .
In the same SO thread, Steve Kuo wrote:So much bad advice in that article I don't know where to start
Campbell Ritchie wrote:Somebody is using poor nomenclature; “class fields” usually means static fields. That link seems to be as much about performance as anything else, and as I said earlier, the likely difference will be too small to notice.
Campbell Ritchie wrote:That sounds very confused, and I think you have misunderstood something. A getXXX() method should never change anything.
Campbell Ritchie wrote:I didn't say it was you using poor nomenclature. Sorry for that confusion.
Case 1: According to Paul Clapham's call, "copies data from a field to a local variable":
I created a field is mainArrList on the Main.java file. After that, I proceeded to "copy" the data of the mainArrList field data into the local variable _mainArrList (line 13). After that, I proceeded to remove the element at the index = 2 of the field mainArrList (line 14) and then check the remaining element list of that field (line 15). It can be seen that the element at the index = 2 has been removed.
Next, I removed the index = 5 on the local variable _mainArrList that I used to "copy" the data of the field mainArrList (line 16) and proceed to print the value of the mainArrList field value. It can be seen that it didn't remove the index = 5 on the mainArrList field (line 17) but it removed the index = 5 on the local variable _mainArrList (line 18).
Case 2: Unknown name, temporarily called "assign":
At the Second.java file, I have the field secArrs and the method getSecArrs() return to the field secArrs above. At the Main.java file, I performed "assign" method getSecArrs() and field secArrs for 2 variables, respectively, mainArrs (line 20) and _mainArrs respectively (line 21). After that, I made changes on both variables, namely deleted the element at the index = 2 on the mainArrs variable (line 22) and index = 5 on the _mainArrs variable (line 23). As a result, the element in those two positions was deleted from the secArrs field at the Second.java file, whether above I "assigned" the method or field. It can be said that the two local variables (mainArrs and _mainArrs) are like the "representative" of the field secArrs at Second.java on the Main.java file, so when I change the local variable value will also lead to change of value at the secArrs field.
What does the running of your program tell you?Tan Quang wrote:(2) Conversely, if a getter / field is in the same class that I assigned (by the = sign) into a local variable, this action is that I'm copying the data of that field into the local variable. Therefore, any change in local variable willn't change on getter / field. Right?
Carey Brown wrote:I think you are concentrating on the wrong thing. You are worried about a couple of nano-seconds of performance (maybe) when you don't have a clear mental image of how Java passes around references and under what circumstances the data being referred to is also being copied.
Carey Brown wrote:Here is my work-over of your code. Note that I did away with your "singleton" code in Second because it's not thread safe. My version is the correct way to do it. Also note the helper methods remove() and print() that output what is being done along with the address of the data in memory. You'll see that for all your copying of references you're ending up dealing with only two memory addresses no matter which variable or method you choose.
Not true.Tan Quang wrote:But my code after removing the element on local variable, that element is only removed on local variable, not removed on field.
Carey Brown wrote:Please don't say you are "copying the data" when you are actually copying the reference. Once you "copy" or assign one reference to another then both references now point to the same object in memory, which in your case, is an ArrayList. You still only have one ArrayList with elements that contain values. You haven't made a new ArrayList whose elements contain copies of values in the original ArrayList.
Carey Brown wrote:A = null
B = null
B = A
IF B == null
THEN B = new something
Now, what's in A? well A is still null. putting something into B does not put it into A.
Campbell Ritchie wrote:I am sure there is no such thing as a null object; it would be better to say, “reference to null”.
Please give us a link to that SO thread.Tan Quang wrote:. . . an answer on SO, the address of "reference to null" is 0.
I am afraid you have misunderstood that. The fact that it is always possible to test for xyz == null and xyz == null and get the correct answer shows that null always uses the same (notional) reference and there is only one such memory reference. There is no such thing as a different null.. . . object reference must be different null (aka A != null), right?
Campbell Ritchie wrote:Please give us a link to that SO thread.
How do they know the address of null is 0? The Java Virtual Machine Specification (=JVMS) doesn't specify that. It is also unlikely that there is such a thing as memory location 0. That might be used by the OS for some sort of important code. It is however likely that the JVMS uses a notional reference of 0 to represent zero, false, or null depending on context.
Identity hashcode is certainly not generated based on the address of the object in memory. Unfortunately, there is no documentation about the identity hashcode generation algorithm, the secret lies in the source code of the JVM written in C++ language.
I am afraid you have misunderstood that. The fact that it is always possible to test for xyz == null and xyz == null and get the correct answer shows that null always uses the same (notional) reference and there is only one such memory reference. There is no such thing as a different null.
There are a few errors in that thread. One of them is that no memory is used for the class, which is probably incorrect. A Class<T> object is probably loaded when the class name is used. I can't remember whether that is specified by the language or not.Tan Quang wrote:. . . Does null variable require space in memory
Not a null object, but a reference to null, please. If there is no object behind the pointer, it is impossible to calculate its hash code, but it is very easy to implement identityHashCode() like this:-Taht does not mean the 0 is anything other than a notional address.You can use System.identityHashCode with null object, it will return 0.
There is nothing unfortunate about that. Specifying an algorithm, as earlier versions of hashCode() did, fixes the implementation and restricts the language developes when updating it.. . . Unfortunately, there is no documentation about the identity hashcode generation algorithm . . .
Yes, it is redundant.. . . assigning A to B is redundant).
That code is different from what I said anything about. I haven't looked really carefully, but I think nobody else said that either.Whereas:
. . . like you say:
If you actually get the above code to compile (I couldn't compile it) then a and b (not A and B, please) will point to the same reference. If that isn't null, then a and b are aliases of each other; both point to the same object."Both A and B will point to to the same object in memory..." (omit N words). At this time, B changes the value, A will also change the value.
Campbell Ritchie wrote:There are a few errors in that thread. One of them is that no memory is used for the class, which is probably incorrect. A Class<T> object is probably loaded when the class name is used. I can't remember whether that is specified by the language or not.
Campbell Ritchie wrote:Not a null object, but a reference to null, please. If there is no object behind the pointer, it is impossible to calculate its hash code, but it is very easy to implement identityHashCode() like this:-Taht does not mean the 0 is anything other than a notional address.
Campbell Ritchie wrote:There is nothing unfortunate about that. Specifying an algorithm, as earlier versions of hashCode() did, fixes the implementation and restricts the language developes when updating it.
Campbell Ritchie wrote:That code is different from what I said anything about. I haven't looked really carefully, but I think nobody else said that either.
Campbell Ritchie wrote:If you actually get the above code to compile (I couldn't compile it) then a and b (not A and B, please) will point to the same reference. If that isn't null, then a and b are aliases of each other; both point to the same object.
Campbell Ritchie wrote:We are suspicious about bit.ly because people post all sorts of weird and wonderful things there, some of them hiding malware. Please quote only the part of the bit.ly link after the last / if you think it is legitimate.
Note that does not say definitely that hashCode() returns the memory address, so the most recent version of the same method tells us:-As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the Java™ programming language.)
It says nothing about how hash codes are calculated.As far as is reasonably practical, the hashCode method defined by class Object returns distinct integers for distinct objects.
Campbell Ritchie wrote:Thank you for the O7 link. Unfortunately, Firefox (=Mozilla) gave a severe security warning about that link and wouldn't open it.
Campbell Ritchie wrote:The implementation of methods can vary from version to version. This is what it says about hashCode() in Java6:-
Note that does not say definitely that hashCode() returns the memory address, so the most recent version of the same method tells us:-As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the Java™ programming language.)
It says nothing about how hash codes are calculated.As far as is reasonably practical, the hashCode method defined by class Object returns distinct integers for distinct objects.
Since both ObjecthashCode() and System#identityHashCode() are native methods, it is only possible to see their implementation by opening the JVM code; you can do that with OpenJDK. It is likely, but not certain, that the implementation is similar on Windows®, Unix, and Linux. It is likely but not certain that there is a notional value of 0 because that is the easiest way to implement default values for (non‑final) fields.
It is certain that the real‑life programmer doesn't need to know that sort of implementation details.
Campbell Ritchie wrote:I am sorry if I have not been polite.
Mike Simmons wrote:Just remember, he's named after the soup:
Don't get me started about those stupid light bulbs. |