"SetTextBuf" hjælper ikke meget - er der en bedre løsning

Har du prøvet Readln/Pos?

function FindMig(HvadSkalJegFinde, FilNavn: String): Boolean;
var
  F: File;
  S: String;
begin
  FileMode := 0;
  AssignFile(F, FilNavn);
  Reset(F, 1);
  Result := False;
  while not Eof(F) do
  begin
    ReadLn(F, S);
    Result := Pos(HvadSkalJegFinde, S) <> 0;
    if Result then Break;
  end;
  CloseFile(F);
end;

Jeg benytter Readln nu.. Her er et kode eksempel:
//-----------------------

AssignFile(F, fileName);
SetTextBuf(F, Buf);
reset(F);

Count := 0;
While not Eof(F) do
begin
  Readln(F, Temp);
  if Temp = ':END:' then
      Inc(Count);
  o.s.v.....
end;

CloseFile(F);
//----------------------------------------------

Og det er ikke hurtigt nok? Hmmm, så står jeg på bar bund! :(

Jeg ved ikke om man kan sige det er hurtigt, spørgsmålet er
om man evt. kunne gøre det hurtigere på en anden måde?

Og har "SetTextBuf" overhovet nogen effekt på
læsehastigheden af filen?

Ellers tak for hjælpen:-)

Jeg ved det faktisk ikke... Har aldrig brugt/haft brug for det... :)

Du finder nok ikke noget langsommere end TekstFiler, men jeg kan vamt anbefale BlockRead som du (af "ukendte årsager") ikke er glad for. Når du bruger BlockRead så er der 2 ting der er vigtigt
- Brug en relativ stor buffer (4, 8, 16, 32 eller 64 KByte)
- Når du kalder Reset så kan man vælge at overføre en RecSize, sæt ALTID denne til 1 (F.eks. "Reset(F, 1);"). Hvis du ikke gør så er RecSize 128 og hvis du skriver "BlockRead(F, Buffer, 4096, Res)" så læser du rent faktisk godt 500.000 Kb i stedet for kun 4 KB (noget der kan få BlockRead til at "virke langsom").

En helt anden ting er selve søgningen. I dette sammenhæng efterlader Delphi's egen POS meget at ønske. En Boyer-Moore algoritme kan således nemt "hægte" Delphis egen pos og gøre en søgning indtil flere gange hurtigere. Borrisholt har "noget kode" til dette formål så muligvis han melder sig på banen med dette !?

skal du søge i din text fil eller hvad ?

Jens B

Tekstfilen består af ekstremt mange relativt korte linier(Tags).
Eks.
  :010:
  :202: evt. tekst
  o.s.v...

Jeg skal finde antallet af bestemte tags i meget store
tekstfiler(300MB eller mere). Jeg skal evt. også gemme positionen
på disse tags i tekstfilen, således at jeg kan kopiere en del af tekstfilen over i en anden efter gennemlæsningen.

På nuværende tidspunkt tager det ca. 2 minuter bare at læse en 300MB fil
igennem uden at behandle linierne(Altså med ReadLN). Som jeg før har omtalt, så har jeg også prøvet at benytte "BlockRead", som korrekt
gør læsningen hurtigere med den rigtige bufferstørrelse. Dette gør dog
at jeg nu har en buffer, hvor jeg først skal finde ud af hvor linien
stopper og derefter skal undersøge om denne linie indeholder det jeg
leder efter. Dette gør det mere tungt end ReadLN.

Så det jeg leder efter er måske en hurtig metode til at søge i en Charbuffer?

Stik mig lige din mail adr. Så skal jeg lige sende dig en lille søge dims.

Jens B

Det ville være skide godt:-)

hvis det ikke fylder for meget så:

"Martin-Andersen@e-main.dk"

sendt !

Jens B

Pelle >> Jeg har lige sendt manden vores søge algoritme sjov.... Tror du ikke en turbosearch kan løse problemet for ham ?

Jens B

Hvis du med TurboSearch mener BoyerMoore-Hest-et-eller-andet søge-routinen så er der ikke nogen tvivl om at den kan klare opgaven

Der er noget galt med ovenstående mailadresse.
Kan du ikke sende den til "man@des.dk"

hov martin .. Jeg havde slet ikke set at min mail klient ikke havde sendt min mail ... Den siger domænet ikke eksisterer ....

Jeg har lagt den ud til download her :

http://borrisholt.com/Eksperten/inst.zip

Jens B

fino

tak for hjælpen:-)

Den vil kunne tælle forkomster i din text fil, med en hastighed du bliver bange for ...

Jens B

du blev så stille

jeg skulle lige ud og spise lidt frokost... prøver det nu.

Hvordan fungere dette point-system, jeg har accepteret svaret og
klikket på dit navn. Har du fået dine fortjente point?

Nej dem fik Pelle (pellelil) ... :-)

Jens B

Det er min egen skyld ... Jeg havde ikke posted et svar ...

Jens B

God arbejds-fordeling, du klare opgaven jeg "score fortjensten". Nu vi er igang vil du ha' mit Kontonummer således jeg også kan få udbetalt din løn ?  ;-)

Yep.. den er 5 gange så hurtig

Har "File_Search" problemer med store tekstfiler?

aaahhh

    ffilesize := system.FileSize( f );
    GetMem( fbuffer, ffilesize );

Der skal vist lige fixes lidt for at den kan håndtere store filer:-)

Den virker da fint .... Ellers må du splitte din fil op i mindere stykker ...

Jens B

Ellers må du købe noget mere ram ..-

Jens B

Ja... jeg kunne jo købe noget mere ram...

Nej... jeg prøver at splitte filen op:-)

How oges ... virker det ?

Jens B

Den virker fint... meget kvik!

Løsningen for mig er nok at udvide "file_Search" lidt, således at
den kan håndtere en given buffer ad gangen. Evt. ved at
lave en "LoadBuffer()" og en "UnLoadBuffer()". På denne måde kan
selv kontrollere hvor meget den skal flæske igennem ad gangen.

Alternativet er at "File_Search" selv skulle kunne splitte filen
op og håndtere det hele selv, men det er nok lidt mere problematisk.

Begge løninger skulle du helst have i luften på under 10 min !

Jens B

Det med at splitte filen er det nemmeste ...

Jens B

Det klart nemmeste er blot at loade hele filen også lade Windows håndtere resten ...

Du ved Page file ...
Jens B

Problemet er at du ikke altid kan oprette en buffer på samme
størrelse som filen selv.

Nå jeg vil hejm ....

Jens  B

Hvis du splitte filen op i "flere bidder", så skal du være ekstra opmærksom på de stedet hvor du deler filen. Med andre ord hvis du leder efter "Hest" kan du risikere at "He" står i den ene buffer og "st" i den anden. Du er således nødt til at "gøre lidt gymnastik" for at fange disse situiationer.

Det er bare at dele efter en linje ...

Jens B

borrisholt> Ingen tvivl om at den er nem at fange, jeg ville bare påpeje at man lige skal være opmærksom på "problemer" (det vil jo vare katestrofalt at dele hesten)  :-)

Bestemt :-)

Man kan vel også bare hoppe "Length(Pattern)-1" tilbage før man
læser næste chunk. Således kan man være sikker på at man ikke registrerer et "hit" i hver buffer eller overser det.