Which is faster, and why?

[MLH]

?InStr(1,MyStri ng,vbNewLine & vbNewLine)
5
?InStr(1,MyStri ng,vbCRLF & vbCRLF)
5

???

[Albert D. Kallal]

Re: Which is faster, and why?

"MLH" <CRCI@NorthStat e.netwrote in message
news:ee8o24ltki ao72ger7f1tlqs9 q36ttmd46@4ax.c om...

?InStr(1,MyStri ng,vbNewLine & vbNewLine)
5
?InStr(1,MyStri ng,vbCRLF & vbCRLF)
5
>

I suspect is absolutely no discernible difference between the two
approaches, and they likely will execute the same speed.

Keep in mind that you can probably execute 30 million or more of those InStr
commands in a second (it is the actual string processing inside the command
that the takes up the time). if you're executing the instruction and
hundreds of thousands of times, then the following code would speed things
up a bit:

dim strVBCRLF as string


strVBCRLF = vbCrlf & vbcrlf

do
..........
bla bla bla = InStr(1,MyStrin g,strVBCRLF)

loop

If you just executing the command once in code, then virtually anything you
do right or wrong design wise will not make any discernible difference. In
the above example my optimization simply eliminates the concatenation that
has to be done each time you use the command. Those commands instr commands
execute quite fast, and unless you executing "many" instr commands my above
a elimitation of your concatenation code will not be that noticeable.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKa llal@msn.com

[lyle fairfield]

Re: Which is faster, and why?

On May 15, 7:44 am, MLH <C...@NorthStat e.netwrote:

?InStr(1,MyStri ng,vbNewLine & vbNewLine)
 5
?InStr(1,MyStri ng,vbCRLF & vbCRLF)
 5
>
???

vbNewLine and vbCrLf are pointers to a string, In VBA run within
Access, TTBOMK they point to the same string, that is they have the
same string pointers, (although not the same var pointers, of course):

Debug.Print VarPtr(vbNewLin e), VarPtr(vbCrLf)
Debug.Print StrPtr(vbNewLin e), StrPtr(vbCrLf)
2027540 2027536
109440652 109440652

In the four bytes preceding 109440652 one will find the long integer
4, indicating that this string is four bytes long (unicode).
In 109440652 and the three bytes following one will find the four
bytes 13 (cartridge return), 0, 10 (line feed), 0.

If a test showed that using one is faster than another, I, like you,
would ask, "Why?"

[MLH]

Re: Which is faster, and why?

Exactly.

You certainly have me convinced. I asked because
I was curious, really, nothing more. I had no clue how
to do the analysis. I was more interested in the analysis
than the actual answer. Albert is on-the-money pointing
out that one could run the process a zillion times in a
second.

Here's where I was really going when I made the O.P.

100 BigString = Me!TowCoMemo
110 BigLen = Len(BigString)
120 For i = 1 To BigLen
130 TrashStr = Mid$(BigString, i, 1)
140 If TrashStr = vbNewLine Then
150 HowManyLFs = HowManyLFs + 1
160 LFPositions(How ManyLFs) = i
170 End If
180 Next i

When the For-Next loop completes, I wanted the array to have one
element for each CRLF in the BigString. But for reasons I'm not sure
of, Mid$ is NOT picking up the linefeeds (13's 10's). So line #140 is
never True and HowManyLFs is always zero no matter how many
vbNewLine's there actually are in the paragraphs (the string).

ON THE OTHER HAND, InStr has no problem whatsoever...

InStr(1, BigString, vbNewLine) Then MsgBox "Yes, InStr(1, BigString,
vbNewLine) located a vbNewLine in the big string. Why
is Mid$ not finding it as it plunders through the big string?"

The above ALWAYS finds the linefeeds. But Mid$ does not. I can
program around that, using InStr. But I would like to know why Mid$
is unsuccessful ???

[Bob Quintal]

Re: Which is faster, and why?

MLH <CRCI@NorthStat e.netwrote in
news:e8co24ha94 n94fthooo5ste9b 8b69h2q7b@4ax.c om:

Exactly.
>
You certainly have me convinced. I asked because
I was curious, really, nothing more. I had no clue how
to do the analysis. I was more interested in the analysis
than the actual answer. Albert is on-the-money pointing
out that one could run the process a zillion times in a
second.
>
Here's where I was really going when I made the O.P.
>
100 BigString = Me!TowCoMemo
110 BigLen = Len(BigString)
120 For i = 1 To BigLen
130 TrashStr = Mid$(BigString, i, 1)
140 If TrashStr = vbNewLine Then
150 HowManyLFs = HowManyLFs + 1
160 LFPositions(How ManyLFs) = i
170 End If
180 Next i
>
When the For-Next loop completes, I wanted the array to have one
element for each CRLF in the BigString. But for reasons I'm not

sure

of, Mid$ is NOT picking up the linefeeds (13's 10's). So line #140

is

never True and HowManyLFs is always zero no matter how many
vbNewLine's there actually are in the paragraphs (the string).
>
ON THE OTHER HAND, InStr has no problem whatsoever...
>
InStr(1, BigString, vbNewLine) Then MsgBox "Yes, InStr(1,

BigString,

vbNewLine) located a vbNewLine in the big string. Why
is Mid$ not finding it as it plunders through the big string?"
>
The above ALWAYS finds the linefeeds. But Mid$ does not. I can
program around that, using InStr. But I would like to know why Mid

$

is unsuccessful ???
>

vbnewline is a two character string, a chr(13) followed by a chr
(10). Since your TrashString has a length of ONE character, it can
never be equal to a string containing TWO characters.

faulty program logic in line 130 is why it doesn't work.


--
Bob Quintal

PA is y I've altered my email address.
** Posted from http://www.teranews.com **

[MLH]

Re: Which is faster, and why?

10:4 you are dead on it.
Thx for pointing that out.

>vbnewline is a two character string, a chr(13) followed by a chr
>(10). Since your TrashString has a length of ONE character, it can
>never be equal to a string containing TWO characters.
>
>faulty program logic in line 130 is why it doesn't work.