Replace Better
in [Visual Basic]
|
Prev: How To Know
Next: Array Problem
From: Mike Williams on 27 Dec 2009 08:02 "David Kaye" <sfdavidkaye2(a)yahoo.com> wrote in message news:hh751a$rn9$1(a)news.eternal-september.org... > [1] I think the most important parts are to put the entire text > into a variable and to use Replace to replace the contents of > that variable, that is b$ = the new b$. I'm assuming that VB > is not creating a new memory location for b$, but is reusing > the space. > [2] Well, I tried replacing chr$(j%) with chr$(j%) & chr$(j%), > thereby adding one byte to each replacement, and one would > think forcing VB to make another copy of b$ somewhere. > Oddly enough, the speed does not go up significantly. > It changes to 0.093+. Amazing. Actually I think VB itself almost always creates a new string in a new area of memory, even for simple things. For example, if you have: Dim s1 As String, s2 As String s1 = Space$(10000000) .. . . and if you then time a simple assignment you will probably find that s1 = s1 takes the same time as s2 = s1. Mike
From: Mike Williams on 27 Dec 2009 08:27 "Schmidt" <sss(a)online.de> wrote in message news:uisoAOvhKHA.5608(a)TK2MSFTNGP05.phx.gbl... > RtlMoveMemory aSrc(-2), CLng(j + j), 4 'adjust the new Len-Info Hi Olaf. I'd often thought of doing that myself (reducing the recorded String length behind VB's back) for various jobs I've tackled but I've always worried about any detrimental effects it might have when VB performs its garbage collection and I wondered whether there is a risk of leaving chunks of memory unused but unavailable. Do you know if there are actually any problems in that area, or if it is actually okay to do it? Mike
From: Schmidt on 27 Dec 2009 09:30 "Mike Williams" <Mike(a)WhiskyAndCoke.com> schrieb im Newsbeitrag news:%23lNvThvhKHA.1824(a)TK2MSFTNGP04.phx.gbl... > > "Schmidt" <sss(a)online.de> wrote in message > news:uisoAOvhKHA.5608(a)TK2MSFTNGP05.phx.gbl... > > > RtlMoveMemory aSrc(-2), CLng(j + j), 4 'adjust the new Len-Info > > I'd often thought of doing that myself (reducing the recorded > String length behind VB's back) for various jobs I've tackled > but I've always worried about any detrimental effects > it might have when VB performs its garbage collection and > I wondered whether there is a risk of leaving chunks of memory > unused but unavailable. Do you know if there are actually > any problems in that area, or if it is actually okay to do it? Good you asked that - since the above line really looks "suspicious" and needs explanation - but after all, all the VB-Strings are allocated on the heap - and freed after going "out of scope" with the normal heap-pointer-based freeing- methods of the system (StrPtr(S) - 4 is the heap-pointer). These freeing-methods have not the slightest interests, regarding what is placed as the LenB-info in the first 4Bytes of a (formerly) allocated "heap-area" (the BString). The only mistake one can make is, to put a LenB-info into the first 4 bytes, which exceeds the allocated range (whilst working with such a manipulated string). Aside from that, one can use that "trick" for example, to write a very fast word-parser, passing "normal looking" String-Parameters into SubRoutines as e.g.: ProcessFoundWord(NewWord As String) ....where NewWord is such a "large enough defined" String (defined as e.g. 16kByte String-buffer at class-level, having an integer-array-mapping on it), which is then "shortened" dynamically, by setting the aMapIntegerArr(-2) member, to the LenB of the currently found word (after copying the few char-integers which make up this word, over from the input-source-array). Meaning, one can "translate" from "array-space" into "string-space" very fast, using this technique on a predefined, large enough StringBuffer (declared in a *.bas or at Class-Level) - thereby avoiding all these many small String-allocations, to feed eventual "SubParsing-routines" with "VB-String-parts". I'm using that for a long time now, and never found any "weirdness". Oh, and BTW - VB does not have a garbage-collector (in the "decoupled working" sense) - VB-"Heap-Variables" (be it Objects or Strings or Arrays) are released (heap-freed) as soon as they go out of their defined scope ... e.g. on procedure-exit (if declared at routine-level). And another note with regards to the SafeArray-mapping- technique, which is useful not only on BSTR-content... Most of these "optimized routines", be it on Pixel-Content or on String-content, are compiled with "all advanced" compiler options, to fulfill the "speed-promise" which one expects by using this stuff. Checking *all* advanced compiler-options works well with that in nearly all cases (don't panic <g>), the critical point comes in, if one is using a "dynamic switching" of the safeArray.pvData member *within* a routine (to span the array in question over another memory-range of a different "heap-variable"). In that case (switching the pvData-pointer within the same routine to other areas) one needs to deactivate (uncheck) the first advanced compiler-option (the aliasing-option), to be on the safe side with the "safe-array-stuff". Maybe as general rule: as soon as safe-array-mappings are used, always leave the first option deactivated - this will cost only 3-5% performance in some routines (not in each and every one). Olaf
From: Mike Williams on 27 Dec 2009 10:49 "Schmidt" <sss(a)online.de> wrote in message news:O3dVnKwhKHA.1824(a)TK2MSFTNGP04.phx.gbl... > Good you asked that - since the above line really > look "suspicious" and needs explanation - but after > all, all the VB-Strings are allocated on the heap - and > freed after going "out of scope" with the normal > heap-pointer-based freeing- methods of the system > (StrPtr(S) - 4 is the heap-pointer). These freeing-methods > have not the slightest interests, regarding what is placed > as the LenB-info in the first 4Bytes of a (formerly) > allocated "heap-area" (the BString). Thanks Olaf. That's cleared up my concerns regarding reducing the length info. Mike
From: Larry Serflaten on 27 Dec 2009 12:25
"David Kaye" <sfdavidkaye2(a)yahoo.com> wrote > "Larry Serflaten" <serflaten(a)usinternet.com> wrote: > > >See what you get for this method which does the same job as your post: > [....] > > inc = StrConv(String$(32, 0) & String$(96, 2) & Chr$(0), vbFromUnicode) > [....] > > I'm a bit confused about what the above string conversion does. It appears to > define a variable called "inc" as a Unicode string containing 32 bytes of a > null string, 96 bytes of ASCII 2, and a single byte of the nullstring and > convert the whole mess into plain ASCII. > > But then "inc" appears to be used later as a function. > > Can you explain this to me? I just wanted to keep the code short. As shown inc was declared as a dynamic Byte array. The part that StrConv replaces would look similar to: ReDim inc(0 To 255) As Byte For idx = 32 to 126 inc(idx) = 2 Next Inc is basically a second array to indicate which characters are acceptable and which are not. For those characters out of the 32 to 126 range, the dst 'pointer' would not be incremented: txt(dst) = txt(src) src = src + 2 dst = dst + inc(txt(dst)) The input text was converted to a dynamic Byte array (which for very large strings can be a significant delay) assigned to txt. The src variable visits every other element (because strings are Unicode), and assigns the value back to the txt array at the dst location. [ txt(dst) = txt(src) ] src is then incremented by 2 in preparation for the next loop, and dst is either left where it is or is incremented by 2 depending on the value in the inc array. [ dst = dst + inc(txt(dst)) ] inc has 0 at character offsets that are ignored, and 2 at character offsets that are accepted such that dst is only increment when txt(dst) is an acceptable character. You were correct to say that is did not do the exact same thing, your routine convered Asc values from 0 to 255 while my earlier post only covered Asc values from 0 to 127. Nobody posted a fix that would extend the inc array out to cover those I left out. For example: inc = StrConv(String$(32, 0) & String$(96, 2) & String(128, 0), vbFromUnicode) Which that change, it should reproduce the results you get with your routine. LFS |