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 13:06 Ralph: Thanks for some of the detail. Will take me a bit to digest your response. I also found this which I haven't had a chance to read yet: http://www.codeguru.com/vb/gen/vb_misc/algorithms/article.php/c7495#more Where my concern primarily has always existed is writing code in any language is for the most part easy. Writing extremely efficient code is another thing. Most programming books do the first. I have yet to find one that makes the jump (explains) why you program one way versus another to take advantage of how the compiler handles things in a given language. It seems this info is hard to come by, yet is the key to getting the most out of your program. For example using: If Len(strTest) > 0 Then or this discussion on the most efficient use of large strings. In my case I have a very large program that using very large arrays. I also built in a help section which has a lot of string data. Currently I have the info in a database memo field, which is loaded at runtime from a menu option. (The memo field presents certain maintenance / string revision issues but that's another story). SO, I really appreciate MMs thread, all the excellent responses from everyone, and if some cares to write a book on using VB efficiently with good explanations as to why you do this versus that in code, I'll be the first in line to buy it -- or be glad to help edit it. David "Ralph" <nt_consulting64(a)yahoo.com> wrote in message news:eT3bTsbeKHA.3792(a)TK2MSFTNGP02.phx.gbl... > > "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: David on 10 Dec 2009 13:11 Thanks "Jim Mack" <jmack(a)mdxi.nospam.com> wrote in message news:OGBjchbeKHA.2460(a)TK2MSFTNGP04.phx.gbl... > 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 16:22 "David" <dw85745NOT(a)earthlink.net> wrote in message news:%23WxTMOceKHA.3792(a)TK2MSFTNGP02.phx.gbl... > .... It > seems this info is hard to come by, yet is the key to getting the most out > of your program. > You've opened the gates on this one. <g> I will agree that language specific details can be difficult to come by, but it is out there and is usually uncovered by extensive reading. Some things such as your Len() example, or avoiding variants, are commonly documented and simple to employ. Others, like using keys vs. indexes with VB Collections, or ByRef vs. ByValue, are conditional and any generality will be challenged by an exception (that makes the rule? <g>). But frankly, I disagree with the last part. Such tricks are not the *key* to getting the most out of a program. It is the efficiency of the algorithms and objects employed that will have the most effect. It is less how you write a line, than how those lines are used. Second, consider that "efficiency" can mean different things and that memory (in terms of footprint) and speed can be two opposing goals. The old adage - "You can make it small or you can make it fast, but not both". "Efficiency" usually comes about with some hybrid of the two. Third, I'm not a great believer in "pre-optimization". You can waste a lot of time on something that has minimum effect on the over-all program as most "bottle-necks" never show themselves until you test, and always seem to be caused by something you knew for a fact was not an issue. <g> -ralph
From: Tony Toews [MVP] on 10 Dec 2009 20:44 MM <kylix_is(a)yahoo.co.uk> wrote: >Life is so much more complicated nowadays than when I proudly fired up >my TRS-80 for the first time! And yet so much easier. I wrote an article on using QEMM and Manifest? maybe, to stuff drivers in between 640kb and 1 Mb for DOS/Windows 3.1. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/ Granite Fleet Manager http://www.granitefleet.com/
From: Karl E. Peterson on 10 Dec 2009 21:03
Tony Toews [MVP] used his keyboard to write : > MM <kylix_is(a)yahoo.co.uk> wrote: > >> Life is so much more complicated nowadays than when I proudly fired up >> my TRS-80 for the first time! > > And yet so much easier. I wrote an article on using QEMM and > Manifest? maybe, to stuff drivers in between 640kb and 1 Mb for > DOS/Windows 3.1. Don't go disturbing Mike's golden retirement memories, now, eh? <G> (Boy, do I remember that! Don't *ever* wanna go back there again!) -- [.NET: It's About Trust!] |