Hi

So funktioniert eine DB nicht, das ist da schon etwas geschickter geregelt. Wenn ich mein "endlich mal meine Boomarks aufräumen" ...

ich glaub euch sofort das DB nahe am optimum arbeiten, allerdings von generellen szenarien ausgehend.

Nein, sondern genau dafür, wofür das Dingen ursprünglich gedacht war: um auf einfache Weise nachschauen zu können, ob mit einer recht genau bestimmbaren Wahrscheinlichkeit etwas gecached wurde.

Also mein Cache ist ein Hash in das ich sowieso direkt nachschaue, und statt dessen soll ich x Hashfkten eines Filters starten, der mir nur eine probalistische Aussage gibt, ob mein Wort im Cache ist???

Selbst ob die JS-Ausage "liegt im Cache" hilft mir _hier_ viel hilft, wenn ich im Gegenzug bei jedem Cachen den Filter aktualisieren muss?

Warum nicht gleich als fertige Seite?

Hä? Soll ich zu jedem Wort eine Liste mit HTML-Code der gesuchten Seiten vorhalten???

Ach so, du meinst nur die Ausgabe auf die Suche? das macht 1. bei Mehrwortsuche keinen Sinn, und 2. das generieren der Seite kann nicht wirklich viel teurer sein als sie fertig umzukopieren.

Brächte Vorteile wenn man     nur die Differenzen abspeichern muß, desto mehr Listen passen ins RAM.

Das ist Microoptimierung, vergiss es schnell wieder.
(Du verbrauchst fast schon mehr Zeit diese Differenzen zu erstellen, als sie nachher gewinnen)

wieso, Integeraddition ist mit das billigste was ein Prozessor kann
(bereits früher auf dem 68000er 4 Zyklen), wenn dafür doppelt soviele Listen ins RAM passen und ich dafür sehr viele Plattenzugriffe einspare lohnt es sich extremst.

Mensch, aber selbst wenn, sorry ... wenn das Vokabular sich verdoppelte, müssten halt alle K-Hashes es auch werden. Das sind Sekunden.

... und schon ist das RAM voll.

nein die liegen doch auf der Platte!

Wenn ich damit performant auf Zellen der K-Hashes zugreifen kann, gerne.

Wie denn sonst?

ich steck da im Detail nicht drinnen wann etwas fragmentiert wird, wie die Blockgrenzen laufen, und was daraus für ein Overhead resultiert.
Wenn das alles keine Rolle spielt, gerne.

Die Bäume einer DB sind doch auf viel generellere Anforderungen hin optimiert, die hier gar nie auftreten werden.  Z.B. müssen hier nicht täglich Millionen Postings eingetragen werden

Skalierbarkeit hat hier wenig mit zu tun.

Nein, aber ich denke diese B-Bäume sind auch optimiert zum schnellen Einpflegen und organisieren sehr vieler Daten.

Bye
  rolf