[php]replace functie optimaliseren

[kroeske]

ik gebruik op mijn site een functie om in een text bepaalde namen die in mijn database voorkomen te herkennen en er links van te maken, opzich een hele simpele replace functie echter zijn er 3 problemen mee.

de functie is:

PHP:

function contrib2url($text) {
    global $cfg;
    $mysql = New mysql($cfg['hn'],$cfg['un'],$cfg['pw'],$cfg['db'],0);
    $mysql->query("SELECT id, artiest, cid FROM contributors WHERE cid != 0 AND artiest != '' AND LENGTH(artiest) > 5 order by id desc");
    $num = $mysql->num_rows();
    while($mysql->movenext()) {
        $naam = $mysql->getfield("artiest");
        $id = $mysql->getfield("id");
        $cid = $mysql->getfield("cid");
        $text = preg_replace( "/(^|\s|,!|;)(".preg_quote($naam, "/").")(\s|,|!|&|$)/imS", "\\1<a href='artist.php?cid=".$cid."' class='textlink'>\\2</a>\\3", $text, 1);
    }
    return $text;
}

de problemen zijn op dit moment:
- als de text lang is duurt het een eeuwigheid
- als er veel artiesten voorkomen in een text duurt het een eeuwigheid
- sommige artiesten hebben een klote naam (bijvoorbeeld Do, en nog een paar) waardoor woorden die niet klikbaar moeten zijn dat wel worden. vandaar dat ik er nu de length(artiest) > 5 constraint in heb gezet, maar dat is wel heel slordig.

opzich is dit laatste probleem moeilijk tot niet op te lossen, maar de andere twee wel denk ik.

iemand een suggestie voor deze functie om te optimaliseren?

[Cavorka]

Kan je in plaats van de preg_replace, niet gewoon str_replace doen? Die is volgens mij namelijk veel sneller.

Hoeveel artiesen staan er in je DB? Want als dat er 400000 zijn (oid), ja dan duurt het lang.

[AtleX]

Het nadeel met str_replace is dat hij ook in woorden gaat replacen, je geeft zelf als voorbeeld al Do, maar in "doorbraak" komt dat ook voor en dan heb je in principe iets gereplaced wat je niet wilt. Met preg_replace kan je een fatsoenlijke regexp gebruiken waardoor dat niet gebeurt.

[kroeske]

Cavorka schreef op woensdag 31 augustus 2005 @ 10:21:
Kan je in plaats van de preg_replace, niet gewoon str_replace doen? Die is volgens mij namelijk veel sneller.

Hoeveel artiesen staan er in je DB? Want als dat er 400000 zijn (oid), ja dan duurt het lang.

dat zou kunnen jah, in de database staan (op dit moment) een kleine 40000 artiesten, maar dat zal in de loop der tijd vanzelf groeien. de reden dat ik voor preg_replace had gekozen is omdat ik uiteindelijk toe wou naar het maar 1x replacen van een naam.

AtleX schreef op woensdag 31 augustus 2005 @ 10:24:
Het nadeel met str_replace is dat hij ook in woorden gaat replacen, je geeft zelf als voorbeeld al Do, maar in "doorbraak" komt dat ook voor en dan heb je in principe iets gereplaced wat je niet wilt. Met preg_replace kan je een fatsoenlijke regexp gebruiken waardoor dat niet gebeurt.

is er nog een performace verschil tussen preg_replace en eregi_replace?
laat maar, php.net geeft daar al antwoord op

[ Voor 32% gewijzigd door kroeske op 31-08-2005 10:27 ]

[Janoz]

Dan is het ook niet zo vreemd natuurlijk dat het zo lang duurt. Stel dat een preg ongeveer 1ms duurt (wild guess), dan duurt je lusje dus al meer dan 40000ms wat weer gelijk is aan 40sec.

Misschien is het handiger om deze replace gewoon 1x te doen en vervolgens dit resultaat ergens op te slaan.

[Bosmonster]

Het handigste en eenvoudigste is natuurlijk gewoon zorgen dat je editors de artiestnamen even tussen bepaalde tags zetten, zodat het search/replacen wat eenvoudiger en dus ongeveer 40000x sneller wordt. Dit resultaat kun je dan ook weer cachen.

Bovendien kun je ze die tags laten gebruiken voor veel meer dan alleen artiestnamen en er een algemener auto-link systeem van kunt maken.

[ Voor 23% gewijzigd door Bosmonster op 31-08-2005 11:15 ]

[Verwijderd]

Je zult heel erg na moeten gaan denken over output caching, want dat is de enige manier om, met een grote artiestendatabase, deze functionaliteit op voldoende snelheid te doen is. Daarbij ga ik er vanuit dat de tekst niet niet bijzonder vaak ge-edit wordt. Da's ook eigenlijk wat Janoz zegt dus

[Cavorka]

AtleX schreef op woensdag 31 augustus 2005 @ 10:24:
Het nadeel met str_replace is dat hij ook in woorden gaat replacen, je geeft zelf als voorbeeld al Do, maar in "doorbraak" komt dat ook voor en dan heb je in principe iets gereplaced wat je niet wilt. Met preg_replace kan je een fatsoenlijke regexp gebruiken waardoor dat niet gebeurt.

Lees dat stukje code van de TS even door... en dan voornamelijk die query.

[kroeske]

allemaal bedankt voor de reacties/ideeen.

ik heb er nu zoals gesugereerd output caching bij gebruikt, die elk nieuwsbericht in elk geval een dag in de cache houdt (zodat er maar een lezer per dag is die een langere laadtijd heeft).
heb er gelijk ook maar een functie bij gemaakt die de gecachte pagina verwijderd zodra het nieuwsbericht aangepast wordt.

[Cavorka]

kroeske schreef op woensdag 31 augustus 2005 @ 11:55:
allemaal bedankt voor de reacties/ideeen.

ik heb er nu zoals gesugereerd output caching bij gebruikt, die elk nieuwsbericht in elk geval een dag in de cache houdt (zodat er maar een lezer per dag is die een langere laadtijd heeft).
heb er gelijk ook maar een functie bij gemaakt die de gecachte pagina verwijderd zodra het nieuwsbericht aangepast wordt.

Maak dan meteen dat hij de cache van de nieuwe pagina ook aanmaakt, dan heeft niemand, behalve de persoon die de pagina wijzigt (een admin/modder) er alleen last van.

[AtleX]

Cavorka schreef op woensdag 31 augustus 2005 @ 11:35:
[...]
Lees dat stukje code van de TS even door... en dan voornamelijk die query.

Dat over de minimale lengte had ik wel gezien, maar zoals de TS terecht opmerkt worden kortere artiestennamen dan niet meegenomen (Do, U2, UB40, etc.) en dat is wel de bedoeling.

[crisp]

Wellicht is een omgekeerde aanpak efficienter: je tekst opsplitsen in losse woorden, en voor elk woord dat > 5 karakters is een lookup doen in je database. Eventueel aangevuld met een stukje caching in de vorm van een tijdelijke lookup-array om te voorkomen dat je hetzelfde woord 2x moet opzoeken in je DB.
Aan het eind plak je dan alles weer aan elkaar.