To CHRTRAN() or not to CHRTRAN()

[ChrisRChamberlain]

Hi all,

Making considerable use of CHRTRAN() in an application and was musing on which might be quicker - to check for the existence of a character(s) in a text field and if found, run CHRTRAN() or simply run CHRTRAN() regardless.

From a coding point of view it's one line versus three, and the result's the same whether you do it correctly, ie test for existence, or not.

The obvious way to find out is to run some tests - alternatively someone may already have been down this particular road before and have the answer.

FAQ184-2483 - answering getting answered.​

Chris

http://www.pdfcommander.com

http://www.pdfcommander.co.uk

 

[craigsboyd]

There are alot of variables in this particular quest. I would guess that it really depends on the probability of the particular character existing in the string in question. I know you weren't looking for a guess, but given the information it is the best I can do. The character being sought would have to be less likely enough to appear in the string that it would make up for the time gain (time to chrtran() minus time to search string). I'm sure we are talking a nanoseconds here, so the number of times these commands are run would have to be quite significant. That's my 2 cents Chris.

_{craig1442@mchsi.com}

"Whom computers would destroy, they must first drive mad." - Anon​

 

[ChrisRChamberlain]

craigsboyd

Not exactly sure yet but there are probably around 100 substrings to be checked for - approximately 5-15% might be found but all still need to be checked.

Hence the comment concerning one line of code or three!

FAQ184-2483 - answering getting answered.​

Chris

http://www.pdfcommander.com

http://www.pdfcommander.co.uk

 

[DSummZZZ]

It also depends on which function you would use to check. For instance, "$" is slower than SUBSTR(), but I'm not sure about OCCURS().
But like Craig pointed out, if the odds of a string containing a particular character are better than 50%, you're still going to be using CHRTRAN(), so therefore, you would be make two funtion calls rather than 1 more often than not.
If the character isn't there, CHRTRAN() won't do anyting and you would save that extra function call.

That makes 4 cents.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[craigsboyd]

Chris,

What is the average length of the 100 substrings?

_{craig1442@mchsi.com}

"Whom computers would destroy, they must first drive mad." - Anon​

 

[ChrisRChamberlain]

Dave

Would use either one of the AT() functions family or OCCURS() which would be first choice.

craigsboyd

Shortest substring would be 3 characters, longest approximately 40, the average being 5.

FAQ184-2483 - answering getting answered.​

Chris

http://www.pdfcommander.com

http://www.pdfcommander.co.uk

 

[craigsboyd]

Chris,

Here is a test you can run and modify to do some benchmarking on it...my finding are that the straight CHRTRAN() is always faster than the search first method...however, I had to do it 10000 times to see any appreciable difference at least on my machine here.

*!* Let's make some dummy data - all strings 5 characters in length
LOCAL nCount, nCount2, nWordLength, sItem, nUpper, nLower, lcString

CREATE CURSOR crsTemp(strings c(5))
nUpper = 90 &&ASCII
nLower = 65 &&ASCII
FOR nCount = 1 TO 100 && one hundred records
	sItem = ""
	nWordLength = 5
	FOR nCount2 = 1 TO nWordLength
		sItem = sItem + CHR(INT((nUpper - nLower + 1) * RAND( ) + nLower))
	ENDFOR
	INSERT INTO crsTemp (strings) VALUES (sItem)
NEXT
********************************
*!* RUN THE TESTS
********************************
*!* Run both tests the first time to reduce VFP caching influence on the test
FOR i = 1 TO 10000
	SCAN ALL
		IF OCCURS("M",crstemp.strings) > 0
			lcString = CHRTRAN("M",crstemp.strings,"X")
		ENDIF
	ENDSCAN
ENDFOR

FOR i = 1 TO 10000
	SCAN ALL
		lcString = CHRTRAN("M",crstemp.strings, "X")
	ENDSCAN
ENDFOR

*!* Now Run the tests again and output the result
lnSearchThenReplace = SECONDS()
FOR i = 1 TO 10000
	SCAN ALL
		IF OCCURS("M",crstemp.strings) > 0
			lcString = CHRTRAN("M",crstemp.strings,"X")
		ENDIF
	ENDSCAN
ENDFOR
?SECONDS() - lnSearchThenReplace

lnJustReplace = SECONDS()
FOR i = 1 TO 10000
	SCAN ALL
		lcString = CHRTRAN("M",crstemp.strings, "X")
	ENDSCAN
ENDFOR
?SECONDS() - lnJustReplace

_{craig1442@mchsi.com}

"Whom computers would destroy, they must first drive mad." - Anon​

 

[ChrisRChamberlain]

craigsboyd

Thanks for that - you've just done what I was hoping to avoid, an actual test.

Gut feeling was there would not be any noticable difference, and give me one line versus three anytime.

FAQ184-2483 - answering getting answered.​

Chris

http://www.pdfcommander.com

http://www.pdfcommander.co.uk

 

[dbMark]

This reminds me of the time I rewrote a program to use EVALUATE() rather than the "slower" macrosubstitution command in some subroutines where there was a massive amount of looping.

Officially slower:
REPLACE &thisfield WITH &newdata

Officially faster:
REPLACE &thisfield WITH EVALUATE(newdata)

Note that the macrosubstitution for the field name cannot be changed to EVALUATE().

In tests I found it to be faster if I ran it through a simple loop like 50,000 times. I asked the users to run the program and they never noticed a difference.

Therefore, I would agree to use the simpler CHRTRAN() and not bothering with a separate existence test first. Yes, it's technically better, but the speed benefits will likely be undetectable in actual use.