 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / General 1 / May 2008Which is faster, and why?
?InStr(1,MyString,vbNewLine & vbNewLine) 5 ?InStr(1,MyString,vbCRLF & vbCRLF) 5 ??? > ?InStr(1,MyString,vbNewLine & vbNewLine) > 5 > ?InStr(1,MyString,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,MyString,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.  SignatureAlbert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal@msn.com > ?InStr(1,MyString,vbNewLine & vbNewLine) > 5 > ?InStr(1,MyString,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(vbNewLine), VarPtr(vbCrLf) Debug.Print StrPtr(vbNewLine), 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?" 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(HowManyLFs) = 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 ??? > Exactly. > [quoted text clipped - 32 lines] > 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. SignatureBob Quintal PA is y I've altered my email address. ** Posted from http://www.teranews.com ** 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.
|
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.