IfThen, Loops and speed
M.H. Avegaart
reading http://www.borland.com/delphi/news/delphi_developer/optimizing.html.
"D" <n...@email.com> schreef in bericht
news:7gerphksc894h6209d...@abc.com...
> Hi,
>
> I've got a bunch of if then's like this...
> By a bunch i mean 100+
>
> if (aStr='an 8 character string') then
> begin
> Do stuff;
> end
> else
> if (aStr='an 8 character string') then
> begin
> Do stuff;
> end
> else
> etc.....
>
> Would using CASE be better and faster?
>
> I've got a bunch of ...
>
> while Pos('1 character string',aStr) > 0 do
> begin
> delete(aStr,Pos('1 character string',aStr),1);
> end;
> while...... etc....
>
> The '1 character string' could be any number.
>
> Is there a faster more efficient way to do this?
>
> Mr.Avegaart suggested some code to me in a previous posting that
> involved copying data from one fixed length variable to another.
> That way it was much faster and reduced the need for memory
> re-allocation on each operation. I was doing alot of copy() &
> delete().
>
> Can i pass strings back and forth between 2 variables and do stuff,
> like while pos shown above, along the way?
>
> Is it always a good idea to use SetLength if you know what the length
> of the variable needs to be?
>
> In good old BASIC the FOR TO loop has a STEP option.
> Couldn't find anything mentioned in the OLH.
>
> Is there anything like that in Delphi or something that will do a
> similar thing?
>
> Thanks,
> D
Bruce Roberts
"D" <n...@email.com> wrote in message
news:7gerphksc894h6209d...@abc.com...
> Hi,
>
> I've got a bunch of if then's like this...
> By a bunch i mean 100+
>
> if (aStr='an 8 character string') then
> begin
> Do stuff;
> end
> else
> if (aStr='an 8 character string') then
> begin
> Do stuff;
> end
> else
> etc.....
>
> Would using CASE be better and faster?
You would find it much easier to use a lookup with a case. Create a
tStringList that contains the strings then use "Case aStringList.IndexOf
(aStr) of". In your example you indicate that the strings are 8 characters.
If this is true for all the strings then, instead of a string list, you
could do something like:
const theStrings = '|ABCDEFGH|12345678|IJKLMNOP|';
. . .
case pos ('|' + aStr + '|', theStrings) div 10 of
0 : // its ABCDEFGHI
1 : // its 12345678
. . .
else // its not in the list
end;
>
> I've got a bunch of ...
>
> while Pos('1 character string',aStr) > 0 do
> begin
> delete(aStr,Pos('1 character string',aStr),1);
> end;
> while...... etc....
>
> The '1 character string' could be any number.
>
> Is there a faster more efficient way to do this?
>
> Mr.Avegaart suggested some code to me in a previous posting that
> involved copying data from one fixed length variable to another.
> That way it was much faster and reduced the need for memory
> re-allocation on each operation. I was doing alot of copy() &
> delete().
>
> Can i pass strings back and forth between 2 variables and do stuff,
> like while pos shown above, along the way?
Can you rephrase this question. What do you mean by "pass strings back and
forth"
>
> Is it always a good idea to use SetLength if you know what the length
> of the variable needs to be?
It really depends on what you are going to do with the string. If all you
are going to do is assign it a value then using SetLength is redundant. OTH
if you are going to move characters into it, one at a time, then yes it
makes good sense.
>
> In good old BASIC the FOR TO loop has a STEP option.
> Couldn't find anything mentioned in the OLH.
>
> Is there anything like that in Delphi or something that will do a
> similar thing?
>
You need to use a While to achieve the same effect in Pascal:
i := baseValue;
while i <= finalValue do
begin
// your stuff
inc (i, stepValue);
end;
AlanGLLoyd
writes:
>I've got a bunch of if then's like this...
>By a bunch i mean 100+
>
>if (aStr='an 8 character string') then
>begin
>Do stuff;
>end
>else
>if (aStr='an 8 character string') then
>begin
>Do stuff;
>end
>else
>etc.....
>
>Would using CASE be better and faster?
>
You can't do a CASE statement directly on strings, but put them in a sorted
TStringList. Then do
SLIndex := MyStringList.IndexOf(MyString);
if SLIndex > -1 then
Case SLIndex of
0 : Do This;
1 : Do That;
etc
But fill your TStringlist in your code somewhere, then it is properly
documented.
>In good old BASIC the FOR TO loop has a STEP option.
>Couldn't find anything mentioned in the OLH.
>
>Is there anything like that in Delphi or something that will do a
>similar thing?
>
Delphi "for" loops only step 1 (or -1 if you use downto), by there's nothing to
prevent you using a multiple of the loop counter. "for i := 0 to 8 step 2 do A
:= B * i;" is the same as "for i := 0 to 4 do A := B * (i * 2);". Alternatively
you could transform it into a "while" loop.
Alan Lloyd
alang...@aol.com
Peter Hellinger
A few days ago I posted an article on delphi3000.com named "Usings strings
with case". Here it is...
Using strings in case statement
Product: Delphi all versions
Category: Object Pascal
Last Update: 06/08/2000
Uploader: Peter Hellinger
Company: Reference: http://www.helli.de
Reference Mail: ma...@helli.de
Question/Problem/Abstract:
How can I use strings in a case statement?
Answer:
Unfortunally the case statement is limited to ordinal types, so you can not
use it with strings.
The idea is to find a way to "convert" the strings to compare in to a
ordinal type. The simpliest way is to think of the strings as an array of
string, and the ordinal representation of a string in this array is its
index.
Delphi gives us the "open array" parameter type for submitting a unknown
number of parameters to a function. Lets use it to retrieve the position of
a string in an array of string:
function CaseString (const s: string;
const x: array of string): Integer;
var i: Integer;
begin
Result:= -1; // Default return parameter
for i:= Low (x) to High (x) do begin
if s = x[i] then begin Result:= i; Exit; end;
end;
end;
Low() gives us the first array member (in most cases 0) and High() returns
the last member. All we now have to do is to look for our searchstring in a
for loop. Looks quite simple, hu? 8-) The function returns the position of
the string s in the array of strings x. This position can be used in the
case statement:
search:= 'delphi3000';
case CaseString (search, ['delphi3000',
'delphipages',
'Torry's']) of
0: s:= 'Excellent!';
1: s:= 'Good source';
2: s:= 'Not bad!';
end;
Update (08. June 2000):
I have made some extensions to the CaseString function to search case
insensitive and to look if the searchstring is in the compared string (Pos).
function CaseString (const s: string; // Search for
ci: Boolean;
// if true looking case insensitive
p: Boolean;
// if true looking if s is in the compared string
const x: array of string): Integer;
var i: Integer;
s1, s2: string;
begin
Result:= -1;
for i:= Low (x) to High (x) do begin
s1:= s; s2:= x[i];
if ci then begin
AnsiUpperCase(s1);
AnsiUpperCase(s2);
end;
if p then begin
if Pos (s1, s2) > 0 then begin Result:= i; Exit; end;
end else begin
if s1 = s2 then begin Result:= i; Exit; end;
end;
end;
end;
AlanGLLoyd
<no.junk.p...@attcanada.net> writes:
>const theStrings = '|ABCDEFGH|12345678|IJKLMNOP|';
>
>. . .
>case pos ('|' + aStr + '|', theStrings) div 10 of
> 0 : // its ABCDEFGHI
> 1 : // its 12345678
>
I think a sorted TStringList (with its quicker search) would be faster than the
above. It would be interesting to do a measurement.
I wonder too whether specifying a string of over a 1000 characters might be
more error-prone than a specifying 8-character strings one at a time for a
string list.
Alan Lloyd
alang...@aol.com
Bruce Roberts
"AlanGLLoyd" <alang...@aol.com> wrote in message
news:20000615172344...@nso-ba.aol.com...
> In article <zo825.10418$qS3....@tor-nn1.netcom.ca>, "Bruce Roberts"
> <no.junk.p...@attcanada.net> writes:
>
> >const theStrings = '|ABCDEFGH|12345678|IJKLMNOP|';
> >
> >. . .
> >case pos ('|' + aStr + '|', theStrings) div 10 of
> > 0 : // its ABCDEFGHI
> > 1 : // its 12345678
> >
>
> I think a sorted TStringList (with its quicker search) would be faster
than the
> above. It would be interesting to do a measurement.
It is an interesting question. It seems obvious that for small numbers of
entries the overall overhead of the above would be lower. I suspect that
unless one has a pretty large number of entries Pos will still be faster
since its sitting in a fairly tight processor loop. Maybe someone will have
the time to check it out.
>
> I wonder too whether specifying a string of over a 1000 characters might
be
> more error-prone than a specifying 8-character strings one at a time for a
> string list.
I know the string list is the greatest thing since sliced bread ;-) but
specifying a long string constant is no more error prone, e.g.
const aLongStringConstant = '|"
+ 'A value|'
+ 'Another value|'
+ 'Yet another value|'
+ 'I trust you get the idea :-)|'
;
Although I'd probably put it all in a file and load it in a run-time. That
way I don't have to recompile the darn thing every time I find a mistake -
in which case I'd use a string list because its one line of code to load.
Bjørge Sæther
news:7gerphksc894h6209d...@abc.com...
> Hi,
>
> I've got a bunch of if then's like this...
> By a bunch i mean 100+
>
> if (aStr='an 8 character string') then
> begin
> Do stuff;
> end
> else
> if (aStr='an 8 character string') then
> begin
> Do stuff;
> end
The fastest string-lookup algorithm I've seen so far is a hash-based one. The
idea is, a string is given a numeric representation, and upon a compare the
input string's hash value is used for determining the position it would have
in a list. When the item is located, another value is returned, this may be
an integer, a procedure pointer or whatever one needs.
The pseudo-code could be as follows:
var
StringHash: THash;
procedure ProcessFirstString;
begin
...
end;
procedure ProcessSecondString;
begin
...
end;
procedure InitHashTable;
begin
StringHash:=THash.Create;
with StringHash do begin
Size:=some_large_enough_prime // avoid duplicate hash values in
registered strings
Add('FIRSTSTRING', @ProcessFirstString); // register the "key strings"
Add('SECONDSTRING', @ProcessSecondString);
...
Add('LASTSTRING', @ProcessLastString);
end;
end;
procedure DoIt(const S: string);
var
ProcPtr: Pointer;
begin
ProcPtr:=StringHash.Hash(S); // find the corresponding procedure pointer
if ProcPtr <> nil then
TProcedure(ProcPtr) // .. and call this procedure
else
DoSomethingElse;
end;
Well, it's an idea...maybe not the easiest, but it sure is fast.
If you're interested, search for 'hash NEAR delphi' on www, or email me for a
unit I found a while ago.
--
Bjoerge Saether
Consultant / Developer
Asker, Norway
bsaether....@online.no (remove the obvious)
Bruce Roberts
> Yes it is 8 characters always, in that spot of code anyway.
>
> Will that be 'alot' faster than the 100+ if/then's?
I'm not sure how optimized the case statement is, but probably. IMO you
really shouldn't worry too much about speed until you've got the thing
working. I've always felt that an easy to read, easy to maintain, bug free
but slow program was much better than a fast program that doesn't work.
>
> This is the example Alan Lloyd posted in reply to some code i had
> posted. In the thread i was asking about finding CRLF in a Memo or
> Richedit.
>
> OldText := Memo1.Text;
> SetLength(NewText, Length(OldText));
> j := 1;
> for i := 1 to Length(OldText) do
> if OldText[i] is GoodChar then begin // do whatever check is
> necessary
> NewText[j] := OldText[i];
> inc(j);
> end;
> {end; for i := 1 to Length(OldText)}
> SetLength(NewText, j - 1);
> Memo1.Text := NewText;
>
> By pass the strings back and form i mean kind of what Alan had shown
> me but i need to do alot of checks for certain strings to remove. So i
> thought of using 2 string variables and passing the text from one
> variable to another. On each pass 1 test is performes.
>
> The way the text is copied from NewText to OldText and SetLength got
> me thinking about the string1 <--> string2 thing.
>
> aStr1 := 'This is an example string'
> aStr2 := ''
>
> What i want to do is... (maybe)
>
> Setlength
> While copying aStr1 to aStr2
> perform a test
> Setlength
> While copying aStr2 to aStr1
> perform a test
> Setlength
> While copying aStr1 to aStr2
> perform a test
> Setlength
> etc, etc......
Sure you can do this.
If you are trying to strip a number of single characters out of a string
then you can do so all in one go using a set.
SetLength (str2, Length (str1));
j := 1;
for i := 1 to Length (str1) do
begin
if not str1 [i] in [chr1, chr2, . . ., chrN]
then begin
str2 [j] := str1 [i];
inc (j);
end;
end;
SetLength (str2, j);
If you do a lot of this stuff, then put it all in a function:
type
tCharSet = Set of char;
function StripChars (str : string; strip : tCharSet) : string;
var i, j : integer;
begin
SetLength (result, Length (str));
j := 1;
for i := 1 to Length (str) do
begin
if not str [i] in strip
then begin
result [j] := str [i];
inc (j);
end;
end;
SetLength (result, j);
end;
Then you can call it whenever you need to strip characters.
Beli
J French
You have 100+ 8 Byte Strings that you are looking for.
Doing 100 string comparisons will take about the same setup time as
doing 100 Pos searches.
Obviously the time spent in a Pos search is longer - but the real time
is spent on setup.
As soon as you abstract the 'test' from the code you are going for,
using Pos, Hashing, TStringLists or anything else you have had it
from the point of view of easy legibility.
So if you are going to lose legibility then you might as well go for
speed and tackle legibility later.
I personally would read the data in from a file
'AAAAAAAA', 1
'BBBBBBBB', 2
'CCCCCCCC', 99
'DDDDDDD', 4
and build one string or chunk of memory contining:
'AAAAAAAA' + 'BBBBBBBB' +
Keep the reference numbers in a parallel array.
The fact that the data is in multiples of 4 bytes is well useful,
you can access the data as an array of Int64s
If they are sorted then you can do a binary chop on them.
This is many times faster than scanning.
You might get better speed if you set it up as TWO arrays of integers
as the DWORD is the native data fetch size, and you would have to work
quite hard to prevent Delphi aligning your array on 4 byte boundaries.
So now you have a 'black box' that returns you a number.
Now one needs to restore legibility to the program
Select Case is NOT the answer here - you just land up doing loads of
comparisons with numbers.
It is just a tidier way of writing If Then Else If Then Else
Build an array of Pointers to procedures/functions so you just just
jump to say :
Procedure AAAAAAA_1( Param1:Integer; Param2:String) ;
Procedure CCCCCCC_99( Param1:Integer; Param2:String) ;
Sure - to build the Array of jumps in the first place will require a
block of code like:
J[ 0 ] := @A_Nasty_Case ;
J[ 1 ] := @AAAAAAAA_1 ;
J[ 2 ] := @BBBBBBBB_2 ;
But you can - and realistically should - write a simple program that
builds that from your main parameter file.
You will then land up with MORE legible code then all those :
If Then Else If Then Else statements
And it will be lightning fast.
Given that your string search - that is now a number search - is a
pretty simple routine - and that it is tucked up in a 'black box' - I
would now be very tempted to convert it into inline ASM
===================================================
In an earlier posting you talked about using :
OldText := Memo1.Text;
SetLength(NewText, Length(OldText));
j := 1;
for i := 1 to Length(OldText) do
if OldText[i] is GoodChar then begin // do whatever check is
necessary
NewText[j] := OldText[i];
inc(j);
end;
{end; for i := 1 to Length(OldText)}
SetLength(NewText, j - 1);
Memo1.Text := NewText;
Given that the New string is not - in your example going to be longer
than the old string - why complicate matters with a new string:
MyText := Memo1.Text;
j := 0;
for i := 1 to Length(MyText) do
Begin
if MyText[i] is GoodChar then
begin // do whatever check
inc(j);
MyText[j] := MyText[i];
end; {If}
end; {For}
SetLength(MyText, j );
Memo1.Text := MyText;
Even if you want a copy of the string, not just to modify it, it is
easier to work on just one thing at a time.
It should also be faster, as when you WRITE a byte the processor has
to fetch a DWORD, insert the byte then write the DWORD
By re-writing the same byte the processor should not have to do the
fetch. Obviously this is just quibbling if GoodChars are rare !
Good Luck
VBDis
(AlanGLLoyd) schreibt:
>>case pos ('|' + aStr + '|', theStrings) div 10 of
>> 0 : // its ABCDEFGHI
>> 1 : // its 12345678
>>
>
>I think a sorted TStringList (with its quicker search) would be faster than
>the above. It would be interesting to do a measurement.
Despite the possibly time consuming Delphi implementation of all string
handling, it should be considered that string scans and compares are machine
instructions, which can execute very fast, as long as the patterns are case
sensitive. So Pos may not be appropriate, but I don't understand the D4
documentation here, which says "Pos ignores case-insensitive matches". IMO a
case-sensitive match also is a case-insensitive match, but not the other way
round.
There exists better methods, to match a given string with one of several
patterns. Just a numerical comparison would be faster, when the strings of 8
characters are treated as 2 integers instead. A hashed search also might be
much faster, where often a single (the first) character can be used to select a
single possible matching pattern, and then the whole string must be compared
only against that single pattern string.
DoDi
Bruce Roberts
> On Fri, 16 Jun 2000 00:23:21 -0400, "Bruce Roberts"
> <no.junk.p...@attcanada.net>, wrote in
> <bYh25.10621$qS3....@tor-nn1.netcom.ca>:
> The testing i want to do along the way is for strings of varying
> lengths. The first test might be for 7 characters, 2nd 10, 3rd 5,
> etc.... What i'm doing is searching for strings to remove so gradually
> the result string gets smaller or atleast stays the same size.
>
> Does that change this greatly with respect to your code above?
Yes. The code I gave only works for excluding single characters. You cannot
use it to exclude sub-strings. For sub-strings the easiest method is to use
a function that removes one pattern at a time. There are some very good
algorithms for dealing with this efficiently and a search of this NG on deja
should produce some sample code. If not you could probably ask for a sample
and I'm sure someone would post a snipet.
AlanGLLoyd
<no.junk.p...@attcanada.net> writes:
>SetLength (str2, j);
>
SetLength (str2, j - 1);
It's the damn limit operation always gets you <gg>
Alan Lloyd
alang...@aol.com
Bruce Roberts
"J French" <je...@iss.u-net.com> wrote in message
news:394a005b...@news.u-net.com...
>
> You have 100+ 8 Byte Strings that you are looking for.
>
> Doing 100 string comparisons will take about the same setup time as
> doing 100 Pos searches.
>
> Obviously the time spent in a Pos search is longer - but the real time
> is spent on setup.
>
> As soon as you abstract the 'test' from the code you are going for,
> using Pos, Hashing, TStringLists or anything else you have had it
> from the point of view of easy legibility.
If the search is in a function, for example, then the code can actually be
made much more readable:
if WordInString ('Hello', aString)
then . . .
It doesn't matter how WordInString is implemented. This code is as readable
as it gets and it doesn't matter how WordInString is written, so long as it
produces the desired result. In fact one could try different versions of
WordInString to find an optimal solution without disturbing the main code.
(If one had a different unit for each WordInString implementation, then
meerly changing a unit name in the uses clause and recompiling would be all
that was needed to try different solutions.)
One of the approaches that I like to use in solving a complex problem is
'top-down'. I suspect that the author of the original post could apply it
with good results to his problem.
>
> So if you are going to lose legibility then you might as well go for
> speed and tackle legibility later.
>
> I personally would read the data in from a file
>
> 'AAAAAAAA', 1
> 'BBBBBBBB', 2
> 'CCCCCCCC', 99
> 'DDDDDDD', 4
>
> and build one string or chunk of memory contining:
>
> 'AAAAAAAA' + 'BBBBBBBB' +
>
> Keep the reference numbers in a parallel array.
Why have reference numbers at all. One is working with fixed length strings
so some simple math will produce an index, e.g. position div sub string
length. But the cost of building this string shouldn't be much less than
using a string list loadfromfile of a sorted list. Then one can use the
IndexOf method which will do a bin search. Much less programmer code and one
would have to write some pretty fancy code to beat its performance
significantly.
<snip>
>
> Select Case is NOT the answer here - you just land up doing loads of
> comparisons with numbers.
> It is just a tidier way of writing If Then Else If Then Else
Does no version of Delphi do optimization on case labels, i.e. build a table
of jump addresses (what you suggest below)?
J French
<no.junk.p...@attcanada.net> wrote:
Comments on a response to a reply to a posting
Posted by an ASM programmer
Replied to by a Non ASM programmer
>
>"J French" <je...@iss.u-net.com> wrote in message
>news:394a005b...@news.u-net.com...
>>
>> You have 100+ 8 Byte Strings that you are looking for.
>>
>> Doing 100 string comparisons will take about the same setup time as
>> doing 100 Pos searches.
>>
>> Obviously the time spent in a Pos search is longer - but the real time
>> is spent on setup.
>>
>> As soon as you abstract the 'test' from the code you are going for,
>> using Pos, Hashing, TStringLists or anything else you have had it
>> from the point of view of easy legibility.
>
>If the search is in a function, for example, then the code can actually be
>made much more readable:
>
>if WordInString ('Hello', aString)
>then . . .
True
>
>It doesn't matter how WordInString is implemented. This code is as readable
>as it gets and it doesn't matter how WordInString is written, so long as it
>produces the desired result. In fact one could try different versions of
>WordInString to find an optimal solution without disturbing the main code.
>(If one had a different unit for each WordInString implementation, then
>meerly changing a unit name in the uses clause and recompiling would be all
>that was needed to try different solutions.)
>
>One of the approaches that I like to use in solving a complex problem is
>'top-down'. I suspect that the author of the original post could apply it
>with good results to his problem.
>
Yes - I call it 'black boxing' - oddly I picked up the description
some time ago.
>>
>> So if you are going to lose legibility then you might as well go for
>> speed and tackle legibility later.
>>
>> I personally would read the data in from a file
>>
>> 'AAAAAAAA', 1
>> 'BBBBBBBB', 2
>> 'CCCCCCCC', 99
>> 'DDDDDDD', 4
>>
>> and build one string or chunk of memory contining:
>>
>> 'AAAAAAAA' + 'BBBBBBBB' +
>>
>> Keep the reference numbers in a parallel array.
>
>Why have reference numbers at all. One is working with fixed length strings
>so some simple math will produce an index, e.g. position
*div *
>sub string
>length. But the cost of building this string shouldn't be much less than
>using a string list loadfromfile of a sorted list. Then one can use the
>IndexOf method which will do a bin search. Much less programmer code and one
>would have to write some pretty fancy code to beat its performance
>significantly.
DIV is incredibly expensive.
String list - you *know* what is going on ??
Predicate: Legibility lost -> go for speed
>
><snip>
>
>>
>> Select Case is NOT the answer here - you just land up doing loads of
>> comparisons with numbers.
>> It is just a tidier way of writing If Then Else If Then Else
>
>Does no version of Delphi do optimization on case labels, i.e. build a table
>of jump addresses (what you suggest below)?
>
I seriously doubt it - just work out what it would have to do - how
would you do it - I could not - I am not prescient - is the compiler ?
Conclusion:
Bruce, some 10 years ago I used to work on 'go faster' routines
Today I was bored (and interested) so I applied the same techniques
You lost it on the line when you started talking about TString lists
If you want speed you *have* to control what is going on
PS: I note no comments about the jump table (apart from a vague hope
that Delphi might do it) - did it not look vaguely like the way in
which a DOS device driver works - is it efficient ?
PPS: Look into the problem again - he wants speed - legibility is
*necessary* - given that you know what the (current) processor is up
to, what do you do - optimize against it or 'release' your thread to
unquantified factors.
J French
>There exists better methods, to match a given string with one of several
>patterns. Just a numerical comparison would be faster, when the strings of 8
>characters are treated as 2 integers instead. A hashed search also might be
>much faster, where often a single (the first) character can be used to select a
>single possible matching pattern, and then the whole string must be compared
>only against that single pattern string.
Case insensitive -DoDi you must Assemble - surely ?
>
>DoDi
Bruce Roberts
>
> >Why have reference numbers at all. One is working with fixed length
strings
> >so some simple math will produce an index, e.g. position
> *div *
> >sub string
> >length. But the cost of building this string shouldn't be much less than
> >using a string list loadfromfile of a sorted list. Then one can use the
> >IndexOf method which will do a bin search. Much less programmer code and
one
> >would have to write some pretty fancy code to beat its performance
> >significantly.
>
> DIV is incredibly expensive.
The DIV operation only has to be done once.
> >>
> >> Select Case is NOT the answer here - you just land up doing loads of
> >> comparisons with numbers.
> >> It is just a tidier way of writing If Then Else If Then Else
> >
> >Does no version of Delphi do optimization on case labels, i.e. build a
table
> >of jump addresses (what you suggest below)?
> >
>
> I seriously doubt it - just work out what it would have to do - how
> would you do it - I could not - I am not prescient - is the compiler ?
You are right it doesn't.
>
> PS: I note no comments about the jump table (apart from a vague hope
> that Delphi might do it) - did it not look vaguely like the way in
> which a DOS device driver works - is it efficient ?
>
> PPS: Look into the problem again - he wants speed - legibility is
> *necessary* - given that you know what the (current) processor is up
> to, what do you do - optimize against it or 'release' your thread to
> unquantified factors.
If speed is your only concern then the jump table makes eminent sense, as do
your other suggestions.
I do not think that the original poster wants only speed. In fact I think if
you reread his posts you'll find that he wants a solution to some of his
problems and if they are efficient, so much the better. Based on the level
of questions being asked I'd guess that he'd find some of your suggestions
quite challenging to implement.
If one is going for speed on a text processing system, wouldn't a state
machine prove faster than multiple search and replaces?
Sundial Services
so." Consider the usual implementations for a regular-expression match
function. They parse the pattern, on the fly, to create a state-table
that can be processed very quickly.
In the case at bar, the tests being performed are complex and repetitive
and involve many different patterns or tests being applied to the same
input. It is, indeed, plausible to assume that you could process those
patterns in some way -- doing so only one time [per run] -- and thereby
arrive at a search-tree or state-table that would encompass at least
part of "the total search" (all the patterns) at once.
>Bruce Roberts wrote:
> If one is going for speed on a text processing system, wouldn't a
> state machine prove faster than multiple search and replaces?
------------------------------------------------------------------
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:in...@sundialservices.com (PGP public key available.)
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R): "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/products/chimneysweep