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. Das sind aber nur sehr wenige. Was viel interessanter wäre, aber leider sehr viel Handarbeit erfordert (wer macht das? Genau, keiner) wäre ein Thesaurus. Ich hatte das am Anfang schon mal kurz andiskutiert (ich glaube mit Daniela selber), mußte mich aber recht schnell davon überzeugen lassen, das das einfach zuviel Arbeit ist.

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. (Der wäre dann aber getrennt von DB und Frontend, könnte also ein Drittanbieter einbauen. Du vielleicht?)

Ja. Und um diese Kollisionen aufzuloesen muss dein Hash-Wert genauer sein
als der in der ersten Tabelle, optimalerweise um eine Zweier-Potenz.

Gehst du davon aus dass ich immer die gleiche Hashfunktion benutze? Wieso brauche ich für 256 Einträge 32-Bit Schlüssel???

Ich glaube Christian hat Dich einfach mißverstanden. Du meintest die normale Kollisionsbehandlung durch Mehrfachhashing, oder? 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.

so short

Christoph Zurnieden