Re: VB 6.0 Desktop - Global Variables

Tech-Archive recommends: Fix windows errors by optimizing your registry

Hi,

MikeD schrieb:
"Ulrich Korndoerfer" <ulrich_wants_nospam@xxxxxxxxxxxx> wrote in message news:43EAA4C8.3000409@xxxxxxxxxxxxxxx
Hi,

MikeD schrieb:

...
So, the performance of global variables are slower than local variables. Why? the extra-logic work that compiler has to do.


No. Performance should not be affected in any measurable way (from a user perspective). Now, *memory* usage might be affected, but global variables are not "slower" than local variables. As has been stated, global variables tend to make maintainability much more difficult and, IMO, make bugs much more likely (and more difficult to solve).


It depends on what one means with "global". If it is meant "having project wide scope", then this kind of variables only can live in a module. Making them local by giving them the attribute Private and giving acces by property only or moving it into a class, then access will be (much) slower!

Well, I consider a "global variable" (and even just "global" by itself) to mean a variable declared using either the Global or Public keyword in a standard code module. As you say, having project wide scope, but also without needing a reference to an object.

A variable that is declared
Private and has a property which publicly exposes it is not, IMO, global in any way because it's encapsulated by the object. You need a reference to that object to use it. If you don't have that reference, it's not accessible. So how can that be considered global?

Private variables don't need an object. Access to them via property does not need an object. A simple standard module suffices. So no reference to an object is needed to access them. And how it comes that you think that I think a private variable is global? Did you find some evidence for this in my post? Then please explain.

Now, as far as speed/performance:

I said "in any measurable way (from a user perspective)".


Heck, this is this old boring half breed argument. Of course the performance hit experienced by the user from *one* call will not show up. But think of eg a sorting routine (which are not so uncommon) accessing a memory location by global access or via a property (remember: this is a function call!) over and over again. *This* will show up to the user.

Sure, if you actually want to benchmark (done properly) any speed difference in global variables vs. module-level or local variables or wrapping a module-level variable in a property procedure, I suppose it is probably measurable.

Your'r kidding. "Probably measurable", lol. When you say supposing, it seemingly means you never did measure it. There are *big* differences. Remember again, properties are accessed via function calls.

The difference is going to be so small though that proper scope,
not to mention maintainability and all other benefits associated with using the right scope (which goes hand-in-hand with writing good, clear, legible code), is considerably more important than the few CPU cycles you'll save by inundating your program with dozens or hundreds of global variables.

Everybody is so concerned with "speed". Sure, that's important and something that needs to always be taken into consideration. But what's more important (and ultimately is what really matters most) is "apparent speed" from a user perspective.


One will get apparent speed losses when using property access often.

--
Ulrich Korndoerfer

VB tips, helpers, solutions -> http://www.proSource.de/Downloads/

-----------------------------------------------------------------------
Plea for a bright future for VB classic.
Sign the petition to Microsoft: -> http://classicvb.org/petition/
-----------------------------------------------------------------------
.

Relevant Pages

  • Re: Many global vars in an A97 app - good or bad? Why?
    ... especially the past about appropriate scope. ... >Passing data between forms: why do so few people know about the ... >>Global variables are decidely poorly suited to these two purposes, ... This could be a global class module variable, ...
    (comp.databases.ms-access)
  • Re: How to eliminate this global variable, silent?
    ... Excluding it because it doesn't have global scope is perfectly correct. ... The only argument you can present is: the standard doesn't ... define "global variables". ... yadda yadda. ...
    (comp.lang.c)
  • Re: Trouble with variable scoping
    ... You are confusing file scope with global. ... That is possibly the most common misperception about Perl that I've ... fully-qualify any global variables you decide to use. ... a lexical variable $foo exists in the current scope. ...
    (perl.beginners)
  • Re: for x in... x remains global
    ... Antoine De Groote wrote: ... in a separate scope, but variables are never local to a block. ...
    (comp.lang.python)
  • Re: Incrementing Table Error?
    ... The dynamic SQL has it's own scope, and variables do not exist outside the ... T-SQL by using two @ signs, as there are no global variables in T-SQL. ...
    (microsoft.public.sqlserver.programming)