Article View: borland.public.delphi.language.objectpascal
Article #32418Re: Suggestions for a faster algorithm?
From: Will DeWitt
Date: Sun, 24 Nov 2002 22:17
Date: Sun, 24 Nov 2002 22:17
52 lines
3177 bytes
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-mailReferences:
<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