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: Nobody on 11 Dec 2009 17:48 "Ralph" <nt_consulting64(a)yahoo.com> wrote in message news:ecUm5GpeKHA.2780(a)TK2MSFTNGP05.phx.gbl... > Curious, I too went looking and found it all over the place. Your location > above appears to be from an installation of one of the Windows SDKs with > the > Framework. > > I didn't find it with any of the "Express" versions - but comes with the > 'free' C++ compilers/SDKs. > > [This is past history but found it interesting that it included in three > places with editons of Visual Studio 6 - as part of MsDev, VB98 Wizards, > and > SDK.] > > ie, if anyone wants it - it is everywhere. lol I have "Microsoft Platform SDK for Windows Server 2003 SP1" installed, so that may be it.
From: David on 13 Dec 2009 17:53 Ralph: Your point is taken, not that I necessarily agree -- at least totally. One of the issues -- mine and I'm sure others -- is knowing how the compiler is optimizing without walking through an assembling listing. For example: Is: If Len(strTest) > 0 Then and If Not strTest = "" Then ultimately made into the same binary instructions? You might look at the MASM code and see they're different lines of code, but is the compiler translating this MASM code directly or is it modifying it so the binary is the same and the most efficient? My guess is NOT, but I don't know for sure. If in fact the compiler is ultimately giving the BEST binary possile, then I agree, it is redundant to "pre-optimize". On the other hand, if Not, then knowing which line of code gives the best result -- say speed -- saves quite a bit of code time (however Find / Replace) works to some degree. If you are using someones elses objects or algorithinms then I agree using them as efficiently as possible goes a long way. But remember those objects and algorithms have their own underlying code ( If Len(strTest) > 0 for example) and hopefully the coder opted for the best speed / efficiency. But if you're writing your own objects and algorithims, the requirement for speed / efficiency falls upon you -- the coder -- and that is what I was addressing with my previous comment. Don't want to belabor this point, just that as previously stated, this info IMHO is the most difficult to come by especially for a one man or small coding shop. David "Ralph" <nt_consulting64(a)yahoo.com> wrote in message news:eKOyxHeeKHA.4112(a)TK2MSFTNGP06.phx.gbl... > > "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: Ralph on 13 Dec 2009 20:35 "David" <dw85745NOT(a)earthlink.net> wrote in message news:eY4tTcEfKHA.5292(a)TK2MSFTNGP06.phx.gbl... > Ralph: > > Your point is taken, not that I necessarily agree -- at least totally. > > One of the issues -- mine and I'm sure others -- is knowing how the compiler > is optimizing without walking through an assembling listing. > For example: Is: > > If Len(strTest) > 0 Then > and > If Not strTest = "" Then > > ultimately made into the same binary instructions? You might look at the > MASM code and see they're different lines of code, but is the compiler > translating this MASM code directly or is it modifying it so the binary is > the same and the most efficient? > If you view the assembly from a native compiled executable you will likely see different machine code for both constructs because the code is different. All comparisons in VB are binary. With this statement .... If Len(strTest) > 0 Then you are making one comparison and acting on the result With this statement ... If Not Len(strTest) > 0 Then you are making one comparison, complementing the result, then acting on the new result. I agree. I doubt any stage of the compiling process will short-circuit the test. The former may well be some micro-click faster. More interesting would be to peek at what ... If Len(strTest) <> 0 Then produces. But you would be hard-pressed to invent a practical scenario where either would make much difference. -ralph
From: mayayana on 13 Dec 2009 23:51 > > > > If Len(strTest) > 0 Then > > and > > If Not strTest = "" Then > > > > If you view the assembly from a native compiled executable you will likely > see different machine code for both constructs because the code is > different. > Matthew Curland actually addresses that specific issue in his book. He says that using Len or LenB is notably better because it only reads the BSTR length prefix, while If Not strTest = "" must make a string comparison, and "" itself requires creating a new 6-byte empty string. (p. 358)
From: David on 16 Dec 2009 13:18
RE: >> > >> > If Len(strTest) > 0 Then >> > and >> > If Not strTest = "" Then I was just using this as an example to make the point these type of "tidbits" are hard to find. Haven't seen Curlands book so can't comment one way or the other. As previously stated, it would be nice if you could get a good list, and then code accordingly. For those working with MS, this would be a good addition to any "Help" IDE. "mayayana" <mayaXXyana(a)rcXXn.com> wrote in message news:uz9RujHfKHA.2184(a)TK2MSFTNGP04.phx.gbl... >> > >> > If Len(strTest) > 0 Then >> > and >> > If Not strTest = "" Then >> > >> >> If you view the assembly from a native compiled executable you will >> likely >> see different machine code for both constructs because the code is >> different. >> > Matthew Curland actually addresses that specific > issue in his book. He says that using Len or LenB is > notably better because it only reads the BSTR length prefix, > while If Not strTest = "" must make a string comparison, > and "" itself requires creating a new 6-byte empty > string. (p. 358) > > |