[pago]

Hi.

Da ich endlich mal wieder halbwegs produktiv an SimpleEdit arbeite, habe ich mir die Frage gestellt, an welcher Stelle die implementation eines Cache für's Dateisystem sinnvoll wäre.

Grund ist prinzipiell mal ganz einfach: Der Aufruf der Methode, die mir die Dateien in einem bestimmten Verzeichnis liefert, ist je nach Dateisystem und Menge der Dateien extrem zeitaufwändig. Aktuell habe ich daher z.B. im TreeModel für den Dateibrowser einen Cache eingebaut.
Andere Programmteile benötigen aber ebenfalls Zugriff zum Dateisystem (z.B. der Code zum laden des Projektes - es werden sämtliche Verzeichnisse rekursiv durchsucht und die Dateien geparst).

Durch meine VFS-API habe ich nun zwei Möglichkeiten: Entweder ich implementiere den Cache in den VFS-Implementationen (relativ einfach), oder ich entwickle ein CacheVFS, dass als Wrapper fungiert (etwas aufwendiger).

Vorteil von letzterem wäre natürlich, dass ich die Cache-Logik nicht jedesmal neu schreiben müsste. Nachteil wäre die weniger effiziente Logik und die starke Verschachtelung.

Außerdem könnte ein Dateisystem unter umständen nicht die notwendigen Informationen liefern, um ein Cache zu implementieren (z.B. weil es keine Methode gibt, die die letzte Änderung eines Verzeichnisses angibt - oder sich der Wert dieser Methode nicht ändert, wenn eine neue Datei/ein neues Verzeichnis angelegt wird). Da sitze ich mit so einem globalen Cache natürlich in der Patsche.

Ein weiteres Problem ist ganz einfach, dass ich, durch den Cache, im schlimmsten Fall, das komplette Dateisystem (bzw. dessen Struktur) in den Speicher lade.
Ich wage zu behaupten, dass das nicht so extrem viel Speicher wäre, aber trotzdem. Einige Verzeichnisse könnten unter umständen nur ein einziges Mal geladen werden und blieben dann ewig im Speicher. Das gefällt mir so gar nicht.
Speziell wo ich damit rechnen muss, dass mein System riesige Mengen an Speicher fressen wird, um effektive Coding-Hilfen anbieten zu können (dazu mehr in einem späteren Topic... ).

Außerdem stört es mich, dass durch einen solchen Cache die transparenz verloren geht ("Der Aufruf dieser Methode könnte möglicherweise lange dauern, oder schnell wie der Wind sein. Das hängt ganz davon ab, ob's schon im Cache ist, oder nicht. Um auf Nummer Sicher zu gehen sollte diese Methode also von einem seperaten Thread aufgerufen werden, aber das kann genausogut ne Verschwendung sein.").
Ich könnte natürlich auch noch zwei Methoden zum VirtualFileSystem-interface hinzufügen: isCached(VFSDirectory) und isCacheEnabled()...
Aber irgendwie gefällt mir das nicht so gut... also vielleicht ein Interface CachedFileSystem oder so... (dann bräuchte ich auch nur noch eine Methode... )

Hat zufällig jemand eine Idee, wo sich ein solcher Cache am sinnvollsten unterbringen lassen würde, oder wie ich die Speicherverschwendung minimieren könnte?

Ich würde mich über'n paar Meinungen freuen. Ist ne relativ wichtige Entscheidung und ich möchte da nur ungern irgendnen Mist verzapfen...



Edit: Ich habe jetzt erstmal den Cache direkt in das VFS implementiert (d.h. in die VFS-Implementationen). Mit dem Ergebnis bin ich durchaus zufrieden:

package org.simpleedit.test;
 
import org.simpleedit.vfs.*;
import org.simpleedit.vfs.file.LocalFileSystem;
 
/**
 * @author Patrick Gotthardt
 */
public class CacheTest {
    public static void main(String[] args) throws Exception {
        VirtualFileSystem vfs = LocalFileSystem.getInstance();
        System.out.println("Start fetching /usr/bin");
        long start;
 
        start = System.nanoTime();
        ((VFSDirectory)vfs.getEntry("/usr/bin")).getChildren();
        System.out.println("Time: "+(System.nanoTime() - start));
        System.out.println("");
        System.out.println("Second try (should be cached now)");
        start = System.nanoTime();
        ((VFSDirectory)vfs.getEntry("/usr/bin")).getChildren();
        System.out.println("Time: "+(System.nanoTime() - start));
    }
}
 

Die (erfreuliche) Ausgabe:

Start fetching /usr/bin
Time: 658947000

Second try (should be cached now)
Time: 278000

Etwas über 2300 mal schneller, wobei ich generell erstaunt bin, dass das ganze doch so schnell ist... /usr/bin ist mächtig groß und das auslesen aller Dateien darin dauerte gerade mal 315 Millisekunden (bei nem anderen Versuch, wo ich System.currentTimeMillies verwendet habe). Allerdings hat der zweite Aufruf dann 0 Millisekunden gedauert.

Der Cache selbst verwendet SoftReferences. Also sollte der GC die löschen, wenn der Speicher knapp wird, allerdings so, dass kürzlich verwendete Einträge später gelöscht werden. Müsste akzeptabel sein, denke ich.


Danke für die Hilfe.
Falls noch jemand nen besseren Vorschlag haben sollte: Ich würd mich freuen.