Hi,

Check doch mal wieviele der Suchbegriffe nicht zu den 65000 häufigsten gehören.

Wahrscheinlich die meisten. Merkwürdig? nein, eigentlich gar nicht, denn die ist ein Fachforum, deshalb wird nach Fachbegriffen gesucht, die selten im allgemeinem Wortschatz stecken.

Ich meinte die häufigsten 65000 Suchbegriffe, das sind ja die Fachbegriffe.

Was geht an Optimierung ist ein Cache. Der ist aber natürlich erst dann einzubauen, wenn die Suche selber gut und stabil funktioniert. Wenn es dann überhaupt noch nötig sein sollte.

eher nicht, ich finde die alte Suche aktuell schon performant genug. Für mich ist es eine theoretische Diskussion.

(Der wäre dann aber getrennt von DB und Frontend, könnte also ein Drittanbieter einbauen. Du vielleicht?)

Ähm könnte ich, aber ich bin sicher die DB hat selbst konfigurierbare cachingfeatures die aus Projektsicht favorisiert würden.

Ich glaube Christian hat Dich einfach mißverstanden. Du meintest die normale Kollisionsbehandlung durch Mehrfachhashing, oder?

wenn Mehrfachhashing genestete Hashes sind, ja!

Das ist aber zu aufwendig. Die normalen Methoden sind da einfacher und meist sogar schneller. Der einzige Vorteil der Mehrfachhash-Methode ist es, das die Hashtabellen kleiner gehalten werden können. Idealerweise sollte die Hastabelle etwa 25% größer sein als nötig, beim Mehrfachhashing kann sie jedoch rein theoretisch genau passend sein. Man spart also ein rundes Fünftel Platz, muß aber dafür viele Hashfunktionen vorhalten (bzw dynamisch erzeugen können) und die auch ausführen (wenn man es genau besieht könnte das sogar O(n^2) als Worst Case haben anstatt der üblichen O(n), aber da möchte ich mich nicht ohne genaue Untersuchung festlegen). Es ist also das alte Geschäft: Zeit gegen Raum, Raum gegen Zeit.

Die unmengen an Hashfkt habe ich schon als Bottleneck erkannt, bin davon ausgegangen dass sie einfach nur selten gebraucht werden.

OK, angenommen ich nehme eine für die deutsche Sprache gute Hashfkt die 32 Bit zB \xABCD liefert.

Wenn ich die oberen 16 bits \xAB nehme könnte ich locker eine Tabelle im RAM adressieren. Von dort könnte ich nun eine weitere Tabelle die auf der Platte liegt referenzieren die ich mit den unteren 16 bit  \xCD ansprechen ohne eine neue Hashfkt zu nehmen.

In der RAM-Tabelle könnte dann auch in jeder Zelle, - quasi als Caching - die wichtigsten/häufigsten Schlüssel
aus der Platten-Tabelle liegen, um einen teuren Zugriff zu vermeiden.

Nun sagt ihr nun "um Gottes Willen", das ist nicht speichereffizient, man bräuchte Plattenplatz für 2^16*2^16=4294967296 Zellen, obwohl dort nur viel weniger Schlüsselwörter enthalten sind!!!

Gut jetzt sage ich, was hindert mich daran die untere Tabelle zu verkleinern um Speichereffizient zu sein.
Angenommen es sind nur y Einträge enthalten, mit 2^(x-1)< y <2^x", dann kann ich auch eine Tabelle mit
2^x Einträgen nehmen wobei die oberen x Bits von \xCD
der Schlüssel wären, und die Werte der "unteren" Bits auf die oberen Zellen projeziert werden. Ohne zu viele uneffektive Kollisionen da die ursprüngliche Hashfkt ja bereits gut war.

Mit anderen Worten, wenn die ursprüngliche Hashfkt mit 32 Bit eine gute Verteilung hat, dann eigentlich auch eine abgeleitete Hashfkt mit weggestrichenen Bits. Wie groß x ist merke ich mir in der Mastertabelle im RAM.

Das wäre dann auch speichereffizient, weil ich im Schnitt nur 25% mehr Zellen als Werte bräuchte.

Knackpunkt wäre es also eine gute Hashfkt mit 32 Bit für  die Selfsprache zu finden.

Oder irre ich mich?

Tschau
 rolf