What is advantage of using a resouce file as opposed to a string variable?
in [Visual Basic]
|
Prev: Can't register Windows Scripting Host with Windows 7
Next: SendKeys in VB6 (and Windows Script Host)
From: David on 10 Dec 2009 11:17 Thanks for response Mr. Mack, helps a lot. Two more questions. 1) My guess is string constants (Const strTest As String = "This is a string") and string literals held in any procedure (Dim strTest As String; strTest = "This is a String") are both kept in the string table?. 2) I see a number of references to "virtual memory". Long ago when I took assembly (8086 processor) we had code segments, data segments, extra segments and I believe one other which I don't recall right now. My guess is when people refer to "virtual memory" they mean the compiler is allocating (Dim) or re-allocating (ReDim) the size of the data segment (as needed)? "Jim Mack" <jmack(a)mdxi.nospam.com> wrote in message news:%23GCRopaeKHA.1652(a)TK2MSFTNGP05.phx.gbl... > David wrote: >> The key question for me is memory usage and recovery. >> After reading all the posts, am I correct in "assuming" the >> following: >> >> 1) String literals that reside and are compiled in the EXE remain >> in memory. > > Yes, in virtual memory. > >> >> 2) String literals that are loaded at runtime (say from text file >> or database) can be removed from memory depending on the object >> they are loaded to. For example if a text file is read into a >> MessageBox and the procedure where the Messagbox resides is >> completed, the string is removed from memory. Other objects where >> strings were read and loaded once set = Nothing would remove the >> strings. > > Correct, except that these are not string literals, but variables. > >> >> 3) A Resource file is read and memory allocated when the EXE is >> compiled and the Strings stays in memory -- no memory is recovered. >> when the object using the resource file is set = Nothing. > > It's not that clear-cut. Resources are loaded on demand, and when no > longer needed can be discarded by the OS (since they're static and can > be reloaded if required). That doesn't mean they _will_ be discarded, > only that they can be. > > Which gets us to the crux: unless you have megabytes of string data, > there's really no reason to think about this. Discardable segments > will stay in virtual memory unless there's a triggering event like a > low memory condition. This is rare these days, and again, unless you > have a ton of data, discarding it isn't going to be much help. > > Except for the fact that resources 'package' the data with the EXE, a > separate database or flat file is a better solution, IMO. > > -- > Jim Mack > Twisted tees at http://www.cafepress.com/2050inc > "We sew confusion" >
From: Jim Mack on 10 Dec 2009 11:46 David wrote: > > Two more questions. > > 1) > My guess is string constants (Const strTest As String = "This is a > string") and string literals held in any procedure (Dim strTest As > String; strTest = "This is a String") are both kept in the string > table?. I don't know the exact details of how VB6 does it, but I presume so. This is not a 'stringtable' in a resource, but an internal mechanism of the language / compiler to insure that only one copy of a given string is kept. > 2) > I see a number of references to "virtual memory". > > Long ago when I took assembly (8086 processor) we had code > segments, data segments, extra segments and I believe one other > which I don't recall right now. > > My guess is when people refer to "virtual memory" they mean the > compiler is allocating (Dim) or re-allocating (ReDim) the size of > the data segment (as needed)? No. In modern 32-bit PCs, the OS, in cooperation with the processor, uses demand paging to swap data and code to and from disk (the page file). This is invisible to the process, except for the speed hit caused by the swaps. Each process can theoretically own and address up to 2GB of memory, regardless of how much physical memory is present. In practice, the total of physical memory plus pagefile size is the limit of virtual memory in a given machine, and much of it is available to each loaded process. -- Jim Mack Twisted tees at http://www.cafepress.com/2050inc "We sew confusion"
From: Ralph on 10 Dec 2009 12:03 "David" <dw85745NOT(a)earthlink.net> wrote in message news:u24HiiZeKHA.2188(a)TK2MSFTNGP04.phx.gbl... > The key question for me is memory usage and recovery. > After reading all the posts, am I correct in "assuming" the following: > > 1) String literals that reside and are compiled in the EXE remain in > memory. > No. (Well maybe... it depends. <g>) But as Jim hinted it all depends on what you call "memory". Using your "keys" then I assume you mean "memory" as defined by that number you see when you open up the Task Manager and that nebulous resource/store you can utimately run out of if abused. And by "recovery" you mean bringing in a chunk into that store, then removing it. [ For all that follows: I assume we are talking about compiling a VB project to native code, and I speaking from a 5,000 foot view - ie, some generalization and abstraction. The actual detailed internal working of Windows launcher and VMM take books, and is far more complex that what I'll offer. Also note the eventual answer is don't worry about it. Use sensible common sense programming practices - and all will be well. Just as Jim suggested. ] Sting literals when compiled are placed in a section called the .rdata. There is also an additional optimization that collects all identical strings and replaces them with one reference. All literal strings in the .text section/s are replaced with the address in the .rdata section. Public Sub Junk() Dim strA As String : strA = "Hello World" Dim strB As String: strB = "Good-bye World" Dim strC As String: strC = "Hello World" End Sub In this case the 'seed' string is fetch from a .rdata section, used with the VB String object - its "memory" lifetime is determined by the lifetime of the string object and the VMM's judgement on whether to keep that particular ..rdata section around. (As Jim noted.) The string objects themselves are referenced on the stack, thus they actually 'stay alive' to a degree as long as the stack is alive. So if instead of "Junk()" we did this in Sub Main - then they'll be around for quite a while. If designing for a small in memory footprint you should also take a look at how you are using the stack - you often run out of stack long before heap. If you have this ... Public strA As String : strA = "Hello World" Public strB As String: strB = "Good-bye World" 'ie, outside a routine - global Then the variables themselves are now referenced in a section called the ..bss. Items here (globals) hang around for a long long time. But the .bss itself is a section - parts of which may also be discarded by the VMM if absolutely needed. So No they are not permanently in "memory", but might be. All sections can be dived into smaller sections are accessed through a section table. So to help ease memory requirements and simplify recovery - then treat them the same as any other resource - use them then dump them. > 2) String literals that are loaded at runtime (say from text file or > database) can be removed from memory depending on the object they are loaded > to. For example if a text file is read into a MessageBox and the procedure > where the Messagbox resides is completed, the string is removed from memory. > Other objects where strings were read and loaded once set = Nothing would > remove the strings. > Same as above. > 3) A Resource file is read and memory allocated when the EXE is compiled and > the Strings stays in memory -- no memory is recovered. > when the object using the resource file is set = Nothing. > No. A Resource 'section' is treated pretty much the same as other sections. (again as per Jim it all depends on how you are using it. A VB project doesn't just contain your custom resource. It has many resources already compiled into the exe. That's where all those .frx and ..drx go. Revist Jim's last paragraphs. -ralph
From: MM on 10 Dec 2009 12:29 On Thu, 10 Dec 2009 11:46:44 -0500, "Jim Mack" <jmack(a)mdxi.nospam.com> wrote: > >David wrote: >> >> Two more questions. >> >> 1) >> My guess is string constants (Const strTest As String = "This is a >> string") and string literals held in any procedure (Dim strTest As >> String; strTest = "This is a String") are both kept in the string >> table?. > >I don't know the exact details of how VB6 does it, but I presume so. >This is not a 'stringtable' in a resource, but an internal mechanism >of the language / compiler to insure that only one copy of a given >string is kept. > >> 2) >> I see a number of references to "virtual memory". >> >> Long ago when I took assembly (8086 processor) we had code >> segments, data segments, extra segments and I believe one other >> which I don't recall right now. >> >> My guess is when people refer to "virtual memory" they mean the >> compiler is allocating (Dim) or re-allocating (ReDim) the size of >> the data segment (as needed)? > >No. In modern 32-bit PCs, the OS, in cooperation with the processor, >uses demand paging to swap data and code to and from disk (the page >file). This is invisible to the process, except for the speed hit >caused by the swaps. > >Each process can theoretically own and address up to 2GB of memory, >regardless of how much physical memory is present. In practice, the >total of physical memory plus pagefile size is the limit of virtual >memory in a given machine, and much of it is available to each loaded >process. Life is so much more complicated nowadays than when I proudly fired up my TRS-80 for the first time! MM
From: Ralph on 10 Dec 2009 12:28
"David" <dw85745NOT(a)earthlink.net> wrote in message news:uObCJRbeKHA.3748(a)TK2MSFTNGP02.phx.gbl... > Thanks for response Mr. Mack, helps a lot. > > Two more questions. > > 1) > My guess is string constants (Const strTest As String = "This is a string") > and string literals held in any procedure (Dim strTest As String; > strTest = "This is a String") are both kept in the string table?. > Two different things or two ways of looking at the same thing. (Huh? <g>) Const variables only exists up and till the project is compiled. Using 'const' is a two step process. Say you have .... Const constantTestA As String = "This is a string" Const constantTestB As String = "This is not used" Then elsewhere in your code you say ... Dim strTest As String : strTest = constantTest The VB parser replaces "constantTest" with "This is a string". When the program is compiled then "This is a string" is treated as a string literal and compiled into the .rdata section like any other string literal. 'constantTestB' if never referenced is gone forever. Also if you did this ... Dim strTest As String : strTest = constantTest Dim strJunk As String : strJunk = "This is a string" you will end up with only one reference to the literal "This is a string" in the .rdata - with string optimization on. Note there is a such a thing as a literal string section - open up any executable in a hex editor and page down to the bottom. > 2) > I see a number of references to "virtual memory". > > Long ago when I took assembly (8086 processor) we had code segments, data > segments, extra segments and I believe one other which I don't recall right > now. > Substitute "section" for "segments" and the idea is the same. The principle difference being that back then segments were a specific size and we could compile to different models. ie, a small model would have one stack, one data segment, and one code/text segment. "Extra" segments meant compiling to the large model. I still use the term segments today, and am just as often corrected by some damn kid who never had to go through all that nonsense. <g> -ralph |