Quellcode Optimierung

Das Thema Quellcode Optimierung geht „Hand in Hand“ mit dem Thema Clean Code Development. Denn wenn ich sauberen Code schreibe, dann ist die Chance groß das dieser auch performant ist da ich in der Regel mich von unnötigen Ballast getrennt habe.

java.lang.String

Verwendet man Strings so werden diese in den sogenannten StringPool abgelegt, dieser StringPool ist eine Map<string,string> welche zur gesammten laufzeit der Anwendung existiert und für jeden Thread gleichbleibend ist.

Nehmen wir folgendes kleines Beispiel :

wie wird das Ergebnis sein ?

Was uns gleich zu der ersten Optimierungsmöglichkeit bringt , werden Strings häufig verwendet so sollten diese explizit „private static final“ sein.

String.split, String.matches, String.replaceAll, String.replaceFirst

Sollten Sie Strings verändern wollen und dazu Reguläreausdrücke (RegEx) verwenden wollen so empfiehlt es sich die Klassen Matcher und Pattern dazu zu verwenden da diese sicherer im Umgang mit Regulärenausdrücken sind.
Es ist erwiesen das ein per Handgeschriebenes ersetzten um den Faktor 10 langsamer ist als mit den Matcher und Pattern Klassen.

java.util.Date

Die Klasse java.util.Date sollte nur in ausnahmefällen verwendet werden da diese nur eine Wrapperklasse für den Timerstamp „long“ darstellt.

java.util.Calendar

Für die Berechnung und Verarbeitung von Datumsangaben sowie die Internationalisierung von denen ist die Klasse java.util.Calender bestens geeignet jedoch erzeugt die schon bei der Erstellung einen riesen Overhead an Speicherbedarf ohne das ein Zugriff auf eine Funktion erfolgt ist.

java.text.SimpleDateFormat

Das Formatieren und Parsen von Datums werten übernimmt die Klasse java.text.SimpleDateFormat.
Für die Verwendung sollte man beachten das, wenn diese Klasse mehrmals verwendet wird ein Aufruf erfolgen sollte denn das erstellen dieser Klasse benötigt schon eine menge Zeit und Ressourcen.

Hierzu auch ein kleines Beispiel:

Sicherlich ist das Beispiel etwas überzogen da, jeder vernünftige Programmierer von selbst darauf kommen würde jedoch kommt es in einer Batchverarbeitung schon einmal ungewollt zu so einem Ergebnis.

Hier noch zur Vollständigkeit die Ausgabe welche auch keine Überraschung darstellt :

Boxing und Unboxing

Wenn man von einer Wrapperklasse zbsp. Integer den primitiven Datentyp int haben möchte oder umgekehrt so ist das in Java relativ einfach da dieses Boxing bzw. unboxing übernommen wird wir brauchen nur :

schreiben.

Hier nun ein Beispiel :

Wie zuerkennen ist muss hier mit „System.nanoTime();“ gearbeitet werden da dieser Vorgang schon relativ schnell ist. Jedoch die Summe aus dem ganzen ist doch schon erschreckend :

An diesem Beispiel kann man gut erkennen was das „einfache“ verwenden einer anderen Methode schon bewirken kann.

java.util.Map

Contains vrs. get & null Check

Hat man eine Map mit vielen Einträgen so kann man wenn man einen Eintrag sucht die Methode „contains(Object key)“ verwenden, jedoch ist es effizienter einen wahrscheinlich vorhandenen Wert zu holen und diesen auf NULL zu prüfen.

Hierzu ein „kleines“ Beispiel:

Möchte man nun nach einem ORT anhand der Postleitzahl suchen so ergibt sich folgendes Ergebnis :

Auch hier spricht das Ergebnis für sich selbst, auch wenn es nur in Nanosekunden Bereich sind so ist doch die Summe des ganzen zu betrachten.

TMap

Wenn man ein Map instaziiert so belegt diese schon einige KiloByte an Speicherplatz obwohl noch keine Werte vorhanden sind, möchte man dieses „Problem“ lösen so kann man auf das externe Paket Trove4J zurück greifen.

Dieses Paket hat so ziemlich alle Collections, Sets und Maps implementiert und das ganze sehr Speicherfreundlich umgesetzt.

 

 

 

Verwandte Beiträge

Ersten Kommentar schreiben

Antworten

Deine E-Mail-Adresse wird nicht veröffentlicht.


*