PAROS download!

Das Ziel war nobel: Code aufräumen, schöner machen, refactoren und dokumentieren und dann online stellen.

Die Realität war derart, dass es leider wichtigeres zu tun gibt. Daher stelle ich das PAROS-Projekt, das dieses Jahr auf der SIGMOD war so online wie es ist: lauffähig, und vom Softwareengineeringaspekt ziemlich hässlich. Aber vielleicht kann ja jemand etwas damit anfangen – zumindest die kleinen hacks um größere Graphen auch annehmbar schnell zeichnen zu können.

Ausserdem ist es ein schönes Beispiel, wie man JXMapKit und OpenStreetMap (OSM) zu Forschungszwecken im Bereich Datamining, GIS (GeoInformationssysteme) und auch SpatialIndexing  verwenden kann. Auf der Konferenz kannten viele OSM nämlich erstaunlicherweise gar nicht, obwohl sie auf dem Bereich tätig waren.

Und zur nächsten Version muss ich nochmal nachsehen, ob es nach den Google Maps Terms of Services  immernoch verboten ist, Maps in Nicht-Browser-Anwendungen zu integrieren. Wäre natürlich auch sehr nett, oder weiß jemand Bescheid? (Update Jan. 2011: das ist nicht mehr verboten!)

Relevante Links:

JavaBeans via GUI konfigurieren

Was genau Java Beans isnd und wozu sie konzipiert sind, möchte ich an dieser Stelle nicht komplett und genau ausführen, dazu gibt es schon genügend Literatur (siehe Linkliste unten). Stattdessen möchte ich nur ganz grob das Konzept umreißen, darstellen wozu man Beans (unter anderem) benutzen kann und dann eine kleine Bean-Konfig-GUI zeigen, die mich mehr Zeit gekostet hat, als ich erst dachte …

Was sind Java Beans?

Eine Java Bean ist eine Klasse, die mindestens die folgenden Eigenschaften erfüllt:

  • öffentlicher Standardkonstruktor
  • öffentliche Zugriffsmethoden (also getter/setter für die relevanten Attribute)
  • Serialisierbarkeit (für das folgende Beispiel nicht wichtig)

Nicht viel also. Beispiele sind übrigens alle UI-Klassen von Swing, also zB JButton, JLabel, etc. Tonnenweise zugehörige Literatur kann man sich an einem ruhigen Winterabend gerne zu Gemüte führen

Wozu sind JavaBeans?

Beans kommen in vielen Java-Bereichen vor: GUIs, Servlets, Persitenz, etc. Java Beans bieten die Möglichkeit von außen per Introspection ausgelesen und bearbeitet zu werden, sie enthalten Attribute (Properties), die den Zustand beschreiben, sie können Events auslösen, sie bieten die Möglichkeit der Persistenz und sie können per Customization angepasst werden. Der letzte Punkt ist zugegebenermaßen sehr schwammig. Also kurz dazu zwei Beispiele:

Beispiel 1: GUI-Komponenten als Beans

Wer schon einmal mit einem Gui Editor gearbeitet hat, wie zum Bsp dem NetBeans Gui Builder, gearbeitet hat, hat schon Beans verwendet ohne es vielleicht zu merken. Klickt man zum Beispiel im GUI Builder auf einen JLabel  kann man sich die Eigenschaften des Labels ansehen und diese dort auch gleich konfigurieren. SO kann man bequem und einfach die Hintergrundfarbe, Schriftart, den Text und diverse andere Eigenschaften sofort und bequem ändern, ohne dafür programmieren zu müssen oder erst extra die API zu bemühen um nachzusehen, mit welcher Methode man die vertikale Ausrichtung ändern kann.

Da es natürlich etwas ineffizient wäre, für jede erdenkliche Komponente eine starre Konfig-Oberfläche zu bauen, ist es viel bequemer, per Introspection, die Komponente nach ihren Attributen zu fragen und die entsprechenden Elemente dynamisch erstellen zu lassen. Auf diese Art und weise kann man dann auch jede erdenkliche Bean konfigurieren – egal ob GUI Komponente von Sun oder selbst erstellt.

Beispiel 2: Konfigurierbare Algorithmen als Beans

ImageJ ist ein Java-Programm das einem per API sehr umfangreiche und vor allem schnelle Bildbearbeitung ermöglicht. Des weiteren lassen sich sehr leicht eigene PlugIns schreiben. Will man nun einen beliebigen Algorithmus schreiben, kann man diesen entweder parameterlos starten (z.B: “Bild horizontal spiegeln”) oder man benötigt noch eine Benutzereingabe (“Bild um X-Grad im Uhrzeigersinn drehen”). In ImageJ wurde dabei die Möglichkeit gewählt, einen generischen Dialog erzeugen und auslesen zu können. Alternativ hätte man auch hier JavaBeans einsetzen können um die Gui vollautomatisch erzeugen zu können, ohne dass sich der Programmierer darum kümmern muss.

Eine einfache Beans GUI

Ziel:

  • Eine einfache JavaBean mit einem Double und einem boolean-Wert und
  • ein einfacher Frame mit einem JTable, der aussieht wie die Komponente im NetBeans Gui Builder.

Problem:

  • Wie verknüpft man die ganzen Klassen aus dem java.beans-Package?
  • Wie bringe ich der GUI bei, die Änderungen an die Bean zu propagieren?

Lösung:

Noch nicht ideal aber ausbaufähig, besteht mein Beispiel aus 5 Dateien:

  1. eine BeanModel Klasse die ein DefaultTableModel erweitert
  2. eine BeanTable klasse die einen JTable erweitert
  3. MyTestBean – die eigentliche JavaBean
  4. MyTestBeanBeanInfo – Beanbeschreibungsklasse
  5. TestFrame, der kleine Frame der das ganze visualisiert

Das ganze gibt’s natürlich auch als ZIP zum Download / und als NetBeansProjekt.

Unschön finde ich derzeit, dass ich sowohl das Modell ALS AUCH den JTable erweitern musste. Aber – ehrlich gesagt hatte ich gestern Nacht um halb 12 auch keinen Nerv mehr, das noch schöner zu machen.

relevante Links:

System.gc() – gut gemeint, aber meist unnötig

Vor ein paar Tagen durfte ich mal wieder einen Blick in Fremdcode werfen, um zu sehen, wie die entsprechende Implementierung realisiert wurde. Eine an sich recht übersichtliche Methode, endete dann mit einem System.gc();. Die Intention ist schon klar: “Gib bitte all den Speicher frei, der jetzt noch durch herrenlose Objekte belegt wird.” Das ist zwar gut gemeint, aber im Regelfall erstens unnötig und zweitens oft sogar kontraproduktiv.

Zu den Fakten. Als erstes sollte an der Stelle ein Blick in die API von System.gc() folgen:

Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.

Das heißt die API impliziert hier schon, dass man sich nicht darauf verlassen kann und soll, dass nach dem Aufruf überhaupt irgendetwas passiert ist. (Die nächst schlimmere Lösung, die ich auch ab und zu gesehen habe, ist dann eine Schleife, in der der GC X-mal aufgerufen wird.)

Auf Stackoverflow findet sich eine interessante Diskussion, ob und warum der GC-Aufruf keine gute Idee ist – bzw WANN es eine gute Idee ist, den Aufruf wirklich zu machen. Ein kleines Fazit der ganzen Diskussion:

  • Es wird oft gesagt, dass es Bad-Practice ist, also lass es (naja okay, kein gutes Argument)
  • Die JVM kennt viele GCs, man weiß zur Ausführungszeit gar nicht, welcher GC aktiviert ist und wie er konfiguriert ist. Einfach mal auf der Java HotSpot VM Options nach “garbage collection” suchen.
  • Die sinnvollere Art den GC zu konfigurieren ist nicht ihn einfach aufzurufen sondern ihn zu konfigurieren.
  • Je nach Implementierung, kann ein Stop-The-World passieren. Also dass das gesamte Programm zur Garbage Collection steht.
  • Eventuell geschieht auch gar nichts: http://bugs.sun.com/view_bug.do?bug_id=6668279
  • Die Speicherverwaltung in der JVM ist nicht nur in Stack und Heap unterteilt. Der Heap ist unterteilt in Heap,Young,Tenured und Perm generation. Sun hat viel Zeit in die intelligente Garbage Collection gesteckt. Wenn man sich nicht mit Speicher Verwaltung und Garbage Collection beschäftigt, macht man es wahrscheinlich weniger intelligent als die Automatik.
  • Oracle/Sun schlägt im Tuning Guide “Tuning the Java Runtime System” explizit vor, den Aufruf auszuschalten.
  • .. und vermutlich noch einige weitere Argumente.

Wann es dann wirkliche eine gute Idee ist, den garbage collect selbst aufzurufen, ist dort auch zu lesen. Unter anderem, ist ein manueller GC sinnvoll wenn:

  • Wenn man ein Speicherleck finden will, kann es sinnvoll sein, zu bestimmten Checkpunkten die Garbage Collection zu forcieren (oder es zu versuchen)
  • Wenn man den Speicherverbrauch von Klassen bestimmen will (siehe Posting).
  • Nach einer umfangreichen und langen Initialisierungsphase ist die Tenured-Generation vermutlich voll mit Objekten, die man nicht mehr brauchen wird und die man gleich aufzuräumen will/muss, um zu verhindern, dass der erste spätere GCs lange braucht, da dort enorm viele Objekte herumlungern die schon lange nicht mehr gebraucht werden.
  • Nach einer kurzen Initialisierungsphase sind eventuell viele – später nicht mehr benötigte – Objekte im Speicher, die gar nicht erst in die Tenured Generation wandern sollen.

Interessante Links zum Thema:

Tuning the Java Runtime System

Speicherverbrauch in Java oder “Size does matter!”

Eines der Vorurteile gegenüber Java ist ja der (angeblich) enorme Speicherverbrauch. Frage ich dann, ob denn die entsprechende Applikation schon mal auf Speicherverbrauch geprofiled wurde und welcher Profiler verwendet wurde, gibt es große Augen und Gestammel über HeapSize, OutOfMemoryExceptions und dass in C ja eh alles besser sei. Na, da weiß man doch gleich dass nicht nur Java schuld sein muss. – Hat man mal mit ImageJ gearbeitet, ist man ab und an schon äußerst verwundert, wie schnell Java sein kann – und fühlt sich auch angespornt seine eigenen Kenntnisse  zu erweitern.

Generell gibt es zur Speicherdiskussion (mindestens) zwei Szenarien.

  1. Die Diskussion, wieviel Speicher eine Datenstruktur verbraucht und ob nicht eine andere Speicherstruktur besser ist.
  2. Wir haben eine OOME und müssen sie beseitigen.

Wieviel Speicher verbraucht meine Datenstruktur?

DAS ist jetzt mal wirklich ein Nachteil von Java wie er im Buche steht, denn es gibt per se keine wirklich einfache Möglichkeit, den Speicherverbrauch einer Struktur oder eines Objektes zu ermitteln. Der Artikel From Java code to Java heap ist hier definitiv anzuraten. Hier wird detailierter über den Speicherverbrauch von Klassen eingegangen.

Im Java Specialists Newsletter von 2001(!!) gibt es einen einen Workaround und ein paar weitere Erklärungen – es folgt eine teils Übersetzung aus dem Newsletter:

  1. Jede Klasse belegt mindestens 8 Bytes auf dem Heap (also auch ein new Object()).
  2. Jeder Datentyp belegt 4 Bytes, außer long und double, die 8 Bytes belegen. Achtung, das heißt, auch ein Datentyp byte benötigt dann 4 Bytes. Außerdem wird der Speicherverbrauch nur in 8 Byte Schritten erhöht. D.h eine Klasse mit einem byte Datentyp belegt 8 Byte für die Klasse + 8 Byte für die Daten = 16 Byte.
  3. Arrays sind speicherschonender  – der geneigte Leser darf das gerne selbst nachlesen.
  4. String#intern() kann ordentlich Speicher sparen.
  5. Boolean.TRUE und Boolean.FALSE benötigen weniger als new Boolean(true).

Okay, alles schön und gut. Aber eine komplexere Struktur benötigt dann wieviel genau? Im Java Specialists Newsletter ist dazu eine kleine aber feine Klasse, die hier weiterhilft:

public class MemoryTestBench {

    public long calculateMemoryUsage(ObjectFactory factory) {
        Object handle = factory.makeObject();
        long mem0 = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
        long mem1 = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
        handle = null;
        System.gc();System.gc();System.gc();
        System.gc();System.gc();System.gc();
        System.gc();System.gc();System.gc();
        System.gc();System.gc();System.gc();
        mem0 = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
        handle = factory.makeObject();
        System.gc();System.gc();System.gc();
        System.gc();System.gc();System.gc();
        System.gc();System.gc();System.gc();
        System.gc();System.gc();System.gc();
        mem1 = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
        return mem1 - mem0;
    }

    public void showMemoryUsage(ObjectFactory factory) {
        long mem = calculateMemoryUsage(factory);
        System.out.println(factory.getClass().getName() + " produced " + factory.makeObject().getClass().getName() + " which took " + mem + " bytes");
    }
}

Die ObjectFactory sieht so aus:

public interface ObjectFactory { public Object makeObject(); }

Und am Beispiel einer ByteFactory sieht das wiederum so aus:

public class ByteFactory implements ObjectFactory { 
   public Object makeObject() { return new Byte((byte)33); } 
}

Jup, etwas aufwändig. Aber immerhin ein Ausweg aus dem Dilemma um hypothetische Diskussionen was wohl besser sein könnte. Und ja, DAS ist in C wirklich einfacher – und trotzdem will ich weiter Java verwenden 😀

OMG, OOME – was tun?!

Regel 1: NICHT blindwütig irgendwo irgendwas irgendwie anders machen.
Regel 2: Auch nicht nachdenken und glauben zu wissen wo es weh tut.

Sondern? Messen!
Zum Beispiel mit der JVisualVM, die bei neueren SUN/Oracle JDKs (nicht JRE) bereits im bin-Verzeichnis der JVM mitgeliefert wird. Ist man eh mit NetBeans unterwegs, kann man das Programm auch nochmal von dort direkt profilen. Ich persönlich setze den erlaubten Speicher (also -Xmx) dann gleich kleiner an, damit die OOME schneller eintritt und weniger Daten betrachtet werden müssen.

Mit etwas Glück sieht man dann recht schnell, welche Datenstrukturen (zu) oft im Speicher sind und kann dann gezielter nach den Referenzen suchen, die es eigentlich gar nicht geben sollte.

LinkedList 33x schneller als ArrayList oder “Kenne deine API!”

Für meine Arbeit schreibe ich zum Test gerade ein kleines Plugin für ImageJ, indem ich unter anderem einen Region-Fill Algorithmus brauche – leider tut’s der filler von ImageJ hier nicht – also schnell was selbst zusammengehackt:

Startpunkt initialisieren und in eine Liste damit
while (Liste nicht leer) {
   hole ersten Punkt P aus der Liste
   prüfe Eigenschaften von p.x/p.y auf dem Bild
   if (Eigenschaften erfüllt){
      füge der Liste die Punkte darüber, darunter, rechts und links hinzu
   }
}

Vorher eine ArrayList entsprechend groß initialisiert, damit die nicht dynamisch wachsen muss und gut ist’s.

Moment – in vielen Iterationen werden hinten an der Liste 4 Punkte angefügt. Das geht mit der ArrayList schön schnell, wie man im ArrayList Quellcode unschwer erkennt (wenn die Liste groß genug ist). Aber in jeder Iteration wird vorne das erste Element entnommen. – Ein Blick in den ArrayList-Quellcode offenbart ein “System.arraycopy(elementData, index+1,  elementData, index, numMoved);“. Oha – das riecht eigentlich eher nach einer LinkedList.

Also: Methode profilen, Listentyp ändern, nochmal profilen (mit dem NetBeans Profiler ja kein Thema). Ergebnis: LinkedList ist wie erwartet viel schneller. Ohne meinen ganzen sonstigen Code reduziert sich der Testfall in etwa auf folgende Testklasse:

public class ListTest {

    public static void main(String[] args) {
        List al = new ArrayList(31000);
        List ll = new LinkedList();
        long a = System.currentTimeMillis();
        testWith(al);
        long b = System.currentTimeMillis();
        testWith(ll);
        long c = System.currentTimeMillis();

        System.out.println("ArrayList: "+(b - a) + " ms");
        System.out.println("LinkedList: "+(c - b) + " ms");
    }

    private static void testWith(List list) {
        list.add(new Point(0, 0));
        int i = 10000;
        Point p;
        while (!list.isEmpty()) {
            p = list.remove(0);
            if (i-- > 0) {
                list.add(new Point(p.x, p.y - 1));
                list.add(new Point(p.x - 1, p.y));
                list.add(new Point(p.x + 1, p.y));
                list.add(new Point(p.x, p.y + 1));
            }
        }
    }
}

Das Speedstepping am Notebook nicht vergessen, sonst fährt die CPU am anfang ja noch nicht auf Vollgas und schon rennt der Test. Die ArrayList habe ich auch extra noch mit mehr Elementen initialisiert, als jemals reinkommen. Ausserdem geht die Initialisierung auch nicht in die Messung ein (ist im Vergeich mit dem Rest zwar eh vernachlässigbar klein, aber damit niemand auf die Idee kommt, der Vergleich wäre unfair …).

Ausgabe:
ArrayList: 860 ms  = 100%
LinkedList: 31 ms  = 3,6%

Sieht man sich die API und den Quellcode der beiden Klassen an, verwundert das Ergebnis nicht wirklich. Der unterschied skaliert natürlich auch mit der Anzahl der Iterationen.

Fazit

Ist ArrayList also schlecht? – Klares NEIN! Nur für genau diesen Anwendungfall (vielfaches Einfügen am Ende, vielfaches Herausnehmen am Anfang, kein Zugriff auf Elemente irgendwo dazwischen nötig) ist die ArrayList der Speicherstruktur der LinkedList einfach unterlegen, die genau auf diesen Punkten optimal funktioniert.

Ergo: Know your API! Man sollte sein Handwerkszeug kennen und nicht blindlings einfach das verwenden was man sonnst auch immer nimmt und hoffen, dass Java ein allmächtiges Werkzeug ist, das einem alle Arbeit abnimmt (und dann nacher groß jammern, dass in C++ ja eh alles viel schneller geht). Und wenn man Zweifel hat, ruhig mal einen Blick in den Sourcecode werfen und ausprobieren 😉

Impact of Flash SSDs on Spatial Indexing

Neben Paros war ich auf der SigMod 2010 auch mit einer Veröffentlichung auf dem DaMoN Workshop (Data Management On new Hardware) vertreten. Der Titel der Veröffentlichung war “On the Impact of Flash SSDs on Spatial Indexing“.

Dass SSDs schnell und cool sind, ist ja mittlerweile allseits bekannt. Leider sind sie noch etwas teuer – nichts desto trotz haben sie den unglaublichen Vorteil, dass die Zugriffszeiten bei wahlfreien Lesezugriffen deutlich kleiner sind, da sie nahezu keine Seek-Zeiten aufweisen (also die Zeit in der der Lesearm der regulären Festplatte erst zur richtigen Position gefahren werden muss, bevor gelesen oder geschrieben werden kann). Diese Seek-Zeiten sind gerade bei Datenbankindices einer der bremsenden Faktoren. Da unser Lehrstuhl auf Datenbanken, DataMining und Indexing spezialisiert ist, haben wir uns daher angesehen, wie sich der R*-Baum (einer der Standard-Indices für mehrdimensionale Daten) auf SSDs im Vergleich zu HDDs verhält. Insbesondere, wie die Indices skalieren und wie es mit der Performanz aussieht, wenn höher dimensionale Daten ( > 10 Dimensionen bzw. Spalten) mit einem R*-Baum indexiert werden sollen und wie es sich mit dem Fluch der Dimensionalität verhält.

Fazit: War eine doch recht spannende und vor allem recht praktische Arbeit , da wir nicht einfach nur Modelle durchrechnen wollten, sondern wirklich die Zugriffe auf die Platte sehen und messen wollten – was die Tests auch sehr zeitaufwändig gemacht hat, da Ram und Platte eben doch einen “kleinen” Geschwindigkeitsunterschied haben.

Abstract:

Similarity queries are an important query type in multimedia databases. To implement these types of queries, database systems often use spatial index structures like the R*-Tree. However, the majority of performance evaluations for spatial index structures rely on a conventional background storage layer based on conventional hard drives. Since newer devices like solid-state-disks (SSD) have a completely different performance characteristic, it is an interesting question how far existing index structures proft from these modern storage devices. In this paper, we therefore examine the performance behaviour of the R*-Tree on an SSD compared to a conventional hard drive. Testing various in uencing factors like system load, dimensionality and page size of the index our evaluation leads to interesting insights into the performance of spatial index structures on modern background storage layers.

Die Veröffentlichung kann man auf unserer Website herunterladen: On the Impact of Flash SSDs on Spatial Indexing

Java Memory Model / MultiThreading in Java

Wer sich für das Java Memory Model und insbesondere für Multi Threaded Code und die Probleme mit denen man sich konfrontiert sieht, wenn man multi threaded programmiert interessiert, könnte das Video durchaus interessant finden.

Titel: Advance Topics in Programming Language: Java Memory Model
von Jeremy Manson

[youtube=http://www.youtube.com/watch?v=1FX4zco0ziY]

BASE: Mailbox deaktivieren

Schritt 1

Schritt 2

Schritt 3

Schritt 4

Schritt 5

Neuer Anbieter, neues Glück! Vor kurzem bin ich zu BASE gewechselt, habe aber nicht daran gedacht, die Mailbox gleich deaktivieren zu lassen.

Kein Problem, Mailbox erst mal initialisiert – und gemerkt, dass man sie über die Mailboxnummer nicht deaktivieren kann. Blöd. – Google wird’s schon richten: Eine kurze Suche bietet auch diverse Treffer. Ergebnis – Hotline anrufen oder Mail schreiben. Öh? Kann doch nicht sein, die machen sich damit doch nur selbst viel Arbeit (=Kosten).

Vielleicht doch erst mal in den Kundenbereich einloggen, und siehe da – Base hat das echt kompliziert gemacht:

  1. Einloggen, “Meine Daten ändern”
  2. oben auf “Mein Tarif” (oder auch “Meine Mutlimedia Dienste”)
  3. unter “Übersicht Dienste” bei “Comfort Mailbox” auf “Details” klicken
  4. unten rechts auf “Ändern”
  5. das Häckchen neben “Aktivieren” weg und unten auf “Bestätigen”
  6. fertig

Ohne Mail und ohne Anruf. 😉

Fazit: Der Einstiegslink über “Meine Daten ändern” ist ja wohl arg uninituitiv!! Unter https://www.base.de/Service/Kontakt kann man das Base auch gleich mitteilen 😉

PS: wer von E-Plus zu Base wechseln will, sollte einfach nur die E-Plus Kundenhotline anrufen und NICHT wie ich, bei E-Plus kündigen und bei Base einen neuen Vertrag mit Rufnummernportierung machen. Geht zwar auch, wäre aber wohl deutlich einfacher gegangen.