🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: borland.public.delphi.language.objectpascal
Article #32418

Re: Suggestions for a faster algorithm?

#32418
From: Will DeWitt
Date: Sun, 24 Nov 2002 22:17
52 lines
3177 bytes
"Anthony T.W." <anomyw3@hotmail.com> wrote in message
news:3de14abc$1@newsgroups.borland.com...
> Right now, I use TFileStream.ReadBuffer to read each character, then I
check
> the character, then go to the next on. Is there a better way?

Without even going into the algorithm you use to handle parsing the data,
I'd urge you to read more than one character at a time-- use an array and
read in chunks (like 1k, or 1024 chars (array[0..1023] of char)), then
handle any data that won't evenly fit into the 1k array at the end (by
reading in the full remaining buffer, and processing it a char at a time).
Here's a basic example--

var
  I: integer;
  Buffer: array[0..1023] of char;
  F: TFileStream;
begin
  F := TFileStream.Create('somefile.dat', fmOpenRead or fmShareDenyWrite);
  while ((F.Position + SizeOf(Buffer)) < F.Size) do begin
    F.Read(Buffer, SizeOf(Buffer));
    for I := 0 to SizeOf(Buffer) - 1 do begin
      // process 1024 chars however you do currently
    end;
  end;
  if (F.Position < F.Size) then begin
    I := F.Size - F.Position;
    F.Read(Buffer, I);
    for I := 0 to I - 1 do begin
      // process remaining I chars however you do currently
    end;
  end;
end;

Pretty sure that's correct, it's untested, but you should get the general
idea.  For increased performance, increase the size of the buffer (you
should find at some point that the increase in performance increases so
little at a particular point that increasing it further isn't justified, you
may even consider allocating the buffer dynamically using a configurable
size in the registry or an INI file (or some other settings area)).
Obviously a 1MB buffer would be overkill unless you're dealing with huge
files, at that point it might be worth detaching the processing from the
file reading by making your application multi-threaded (using one thread to
read in buffers, and using synchronization objects to determine when it's
safe to read from a buffer, or when to request the next buffer pointer).
But I have a feeling you won't need anything that advanced.  =)

Will

--
http://qc.borland.com - download the client and vote for the Win32 API
header translation (report 1230)!
Technical Details
Message-ID: <3de14fe4$1@newsgroups.borland.com>
Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-03!sn-xit-06!sn-xit-04!supernews.com!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!news.uni-x.net!newsgroups.borland.com!not-for-mail
References: <3de14abc$1@newsgroups.borland.com>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 109d30,4492917324c52112
X-Google-Attributes: gid109d30,public
X-Google-ArrivalTime: 2002-11-24 15:15:38 PST
From: "Will DeWitt" <edge@NO.SPAM_boink.net>
Newsgroups: borland.public.delphi.language.objectpascal
References: <3de14abc$1@newsgroups.borland.com>
Subject: Re: Suggestions for a faster algorithm?
Date: Sun, 24 Nov 2002 14:17:58 -0800
Lines: 54
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
NNTP-Posting-Host: 66.171.63.57
Message-ID: <3de14fe4$1@newsgroups.borland.com>
X-Trace: newsgroups.borland.com 1038176228 66.171.63.57 (24 Nov 2002 14:17:08 -0800)
Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-03!sn-xit-06!sn-xit-04!supernews.com!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!news.uni-x.net!newsgroups.borland.com!not-for-mail