Slashdot Mirror
Sharp's Upcoming Linux PDA
Bill Kendrick writes: "ZDNet reports that Sharp is getting ready to make its
Linux-based PDA available to developers in the next few weeks. They'll include a 206MHz StrongARM, 32MB (in the cheaper, developer edition), a JVM, the Opera web browser, and a slide-out keyboard. A profile of the device is available at LinuxDevices.com." We've mentioned this before, but it looks like it'll be here soon.
public class SlashdotBitchfest {
public static void main(String[] args) {
String s = "Code monkeys are what make Java performance suck. ";
s += "You can spot a code monkey because they write stuff like this. ";
s += "Java handles String concatenation really badly ";
s += "and each += involves an array copy ";
s += "and the creation of a new immutable String object ";
s += "because a+=b is really syntactic sugar for ";
s += "\nStringBuffer temp = new StringBuffer(a);";
s += "\ntemp.append(b);";
s += "\na = temp.toString();";
s += "\nso you waste resources quadratically ";
s += "and kick the garbage collector into overdrive. ";
s += "You're supposed to allocate memory for a single StringBuffer instead ";
s += "and append() stuff to it in succession. ";
s += "But this isn't obvious. ";
s += "And the fact that += works at all means that ";
s += "the code monkeys will always use it. ";
s += "\"It saves me typing!\" they whine. \"And it WORKS, doesn't it?\" ";
s += "Stopping them is hopeless. ";
s += "\nJava's automatic Unicode support is a bitch too. ";
s += "Half the time you don't need it but you get it anyway \"for free\", ";
s += "but all those Unicode conversions take time! ";
s += "\nEven something like String.toUpperCase() is expensive. ";
s += "(You would think that Sun would be doing this in a loop: ";
s += "\nif (\'a\'=myChar&&myChar=\'z\') myChar-=(\'a\'-\'A\'); ";
s += "\nbut they don't do that. It's more complicated! ";
s += "String.toUpperCase() is actually testing for the German \"ß\" ";
s += "so it can convert it to a pair of letters \"SS\"! ";
s += "It also worries about Chinese characters, Arabic, all that stuff. ";
s += "For Strings that only need to be machine-readable, ";
s += "this is an unnecessary performance hit ";
s += "because you aren't going to have Kanji and Swedish characters ";
s += "in things like database identifiers. ";
s += "\nBut Sun has deprecated all non-Unicode stuff from its API. ";
s += "So often you have to use byte[] arrays ";
s += "or write your own non-politically correct ";
s += "ASCII-only String conversion routines. ";
s += "\nIt IS possible to write very efficient Java code ";
s += "but to do so requires some expertise ";
s += "and you have to pay very close attention to the code you're writing. ";
s += "Code monkeys don't do this. ";
s += "They have no idea what they're doing. ";
s += "Inefficient Java programs are really easy to write ";
s += "because the API hides many details from you ";
s += "and so you often don't realize the performance impact of your decisions. ";
s += "In fact the JVM gets blamed a lot for the lousy performance of ";
s += "many Java programs, but the real culprit is the API which in many ";
s += "places makes too many decisions on its own. It caters to ";
s += "lazy people who don't like to learn how to do things the right way.";
s += "\nWe found a long String concatenation series like this ";
s += "in one of our most frequently called routines, in its innermost loop. ";
s += "Thousands and thousands of += appends were being used to build up a ";
s += "huge String that kept getting copied, replaced, and garbage collected ";
s += "with each +=. Once we fixed it, we got something like a 5000% ";
s += "performance increase. \nGo figure!";
System.out.println(s);
}
}