Static References Optimizer February 01, 2009 04:38 over 3 years ago
Titlen på denne post har jeg snuppet fra et ”white paper” om hastighedsoptimeringer i forskellige J2e applikationsserverer. For nogle år tilbage stod den helt store kamp på applikations markedet mellem ret enkelte egenskaber såsom hastighed, kapacitet eller robusthed.
Denne gang har jeg kun fokus på hastighed og specielt en applikationsserver har forsøgt at markere sig som den absolut hurtigste. Under udviklingen nedsatte de nogle gruppe som udelukkende koncentrerede om at finde og afhjælpe hotspots for at finde yderligere hastighed. Under denne arbejdsindsats fandt de på mange tricks og metoder man kan gøre for at optimere både selve serveren men også i de applikationer som hostes af serveren.
Konklusionerne er omfattende og komplekst men en enkelt tese munder ud i denne sætning: ”Det koster mere at skabe en ny instans af en klasse, end det koster at have en instans og lave et antal kopier.”
Det konkredte problem er at jeg har et ”Command Pattern” der har indkapslet et beregningsmodul. En hver beregning er isoleret og kan leve uden sideeffekter eller delt hukommelse under afvikling. Det uheldige er at beregningerne er koblede gennem et lag med serialisering/deserialisering. Som serialisering tool er valgt XMLBeans og mere end 95 procent af tiden går med at instantiere XMLBeans objekter.
Det er ikke et problem jeg vil løse ved at konstruere en ny applikationsserver men blot bruge samme analogi. Jeg har med succes implementering metoden flere gange og fundet betragtelige hastighedsoptimeringer.
Hemmeligheden er hotspot compileren. Jeg vil ha hotspot til at clone objekter fremfor at new objekter. Metoden provokere hotspot til at lave effektive genveje melle bytecoden og basic CPU instruktioner.
/**
* Static references optimizer
* @see http://en.wikipedia.org/wiki/Java_bytecode
*/
class StaticReferencesOptimizer {
private static XMLBean xmlbean = new XMLBeansDummey.create \AllBeans();
}
Ved applikations start vil disse notificeret beans blive instantieret og ved service kald vil compileren blot lave en kopi. Millionvis af kopier med 90 til 95 procent bedre hastighed end ved at lave nye instanser. Det var alt. Alle de XML beans som skal benyttes skal ind i sådan en klasse i en statisk kontekst og den hastighedsoptimering du kan opnå ved så simpelt indgreb vil overraske dig.
Selv om dette trick er utroligt enkelt er det langt fra alle mainstream Java programmører som forstår de mekanismer som sker i hotspot compileren. Og heldigvis for det. Fra Java’s perspektiv ses en klasse som ikke har referencer til eller fra andre klasser. Det mest normale er at en novice programmør sletter filen.
Her kommer disciplin og dokumentation ind i billedet men det er en anden sag.
By Frank Vilhelmsen - 2 tags: java xml - Add comment