[gtz]

wenn du keine datenbank nehmen oder den inhalt sonst irgendwei idizieren willst, dann hast du schlicht und ergreifend auch keine andere wahl, als jedes mal die komplette filebase zu durchsuchen. da du eh durch alle files durchmusst, ist es auch komplett egal, ob iterativ oder rekursiv, depth-first oder breadth-first suchst.

[bigdeal]

dass die ganze filebase durchsucht werden muss ist auch nicht das problem, nur wüsste ich gerne welcher algorhitmus dafür eben besser geeignet ist, laufzeitverhalten nennt man das afaik (schule is schon so lange her, da haben wir das immer an delphi programmen gemessen)

[gtz]

eben das is vollkommen gleichgültig. unter der annahme, dass du nich etliche files mehrfach durchsuchst oder so. du musst durch alle durch. in welcher reihenfolge is für das laufzeitverhalten total irrelevant.

das einzige, was dir wirklich weiterhilft, is, einen index über deine dokumente anzulegen. das dauert erheblich lange, beschleunigt deine suche aber enorm.

[kaputt]

htdig ist schon ne feine sache. und gerade für solche riesigen statischen webs ziemlich geeignet.

[Lazy-GoD]

Vielleicht findest du da auch ein paar weitere Anhaltspunkte:

http://www.google.de/search?hl=de&q=mnogosearch&btnG=Google-Suche&meta=

[Mac]

Warum nicht die Seiten durchschaufeln, den Schindex als File ins Verzeichnis legen.
Dann durchsuchste nur den Index. Das geht schneller und kannst dann auf das ERgebnis linken.

Den Index kannste per cron starten und/oder vom User nach Updates der Site manuell neu bilden lassen.
Dazu dann vielleicht noch eine Ausschluss-Liste von Wörtern, die nicht mitgezählt werden sollen, wie 'und', 'oder' etc.