toHexString optimization (in fact general optimization question)
Hello,
I have to handle a situation where we export millions of data, after converting them according to user preferences.
Currently I'm working on some hexadecimal conversion I want to optimize:
Code:
String result = Constants.HEX_PREFIX + Integer.toHexString(aInt);
result = result.toUpperCase();
I've looked how the toHexString method was coded in the jdk (rt.jar, or src.zip):
Code:
final static char[] digits = {
'0' , '1' , '2' , '3' , '4' , '5' , '6' , '7' , '8' , '9' , 'a' , 'b' ,
'c' , 'd' , 'e' , 'f' , 'g' , 'h' , 'i' , 'j' , 'k' , 'l' , 'm' , 'n' ,
'o' , 'p' , 'q' , 'r' , 's' , 't' , 'u' , 'v' , 'w' , 'x' , 'y' , 'z'
};
public static String toHexString(int i) {
return toUnsignedString(i, 4);
}
private static String toUnsignedString(int i, int shift) {
char[] buf = new char[32];
int charPos = 32;
int radix = 1 << shift;
int mask = radix - 1;
do {
buf[--charPos] = digits[i & mask];
i >>>= shift;
} while (i != 0);
return new String(buf, charPos, (32 - charPos));
}
My intent is to copy/modify this code according to our special conversion need. The method would looks like that:
Code:
private static final char[] DIGITS = {'0', '1', '2', '3', '4', '5', '6', '7', '8',
'9', 'A', 'B', 'C', 'D', 'E', 'F', 'g', 'h', 'i', 'j', 'k', 'l',
'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z'};
private static String toHexString(int i)
{
char[] buf = new char[32];
int charPos = 32;
do
{
buf[--charPos] = DIGITS[i & 0xF];
i >>>= 4;
}
while (i != 0);
return new String(buf, charPos, (32 - charPos));
}
The reason of this post is that I fear the JVM could optimize the toHexString/toUnsignedString with a native method implementation (because doing this kind of conversion with "pure" java code seems to be unefficient) ?
Is it possible a JVM implementation could do that ?
If it's the case, replacing the toHexString() by a custom method would in fact slow the process down ...
What is your opinion ?
Thanks & regards.
PS: We are using the Oracle JRockit JVM, but I've looked in their rt.jar also, and it is the exact same method.
PS2: I know there are other possible optimization, like adding the HEX_PREFIX directly in our toHexString, and using directly the char[] object or passing a StringBuilder, but that isn't really the concern of this post
low mtbf v greymeat between the human ears
Yep, it's like ftr and Neil state. I did not go into that ( I was sure those issues would be reviewed ) but what see here on a deeper level is going to remarkable effort to get something to "full-tilt-boogie" and those who use the product are neither concerned with the matter nor will they allow your technical skills and deep tweaking to run .... suprisingly this is even if it ran, ran well in testing and deployment and proved robustness under loading with 100,000 hours of 000.00000000007654 statistical failure significance ( and recoverable failure at that ) they would still base decisions on matters more appropriate to Lorimar's production of "Dallas" I know, I have been there: A person who worked with K&R was going to get me a stint as an advisor on equipment selection on a major carrier, in Dallas no less. I tried to warn her, she had a Masters in CS but was not a Road Dog.
She took a 5-10 hour sweat your dress shirts out butt chewin.
This has got to be the most bizzare problem I know of in cs, I am throwing ai at it.
I have zero fantasies that that will be of any use.....
