DWUTKA at marlow.com
DWUTKA at marlow.com
Wed May 18 13:56:59 CDT 2005
I ran it in debug in VB, and got only a slight variation....Longs being
slightly faster. However, your code compiled produced:
3405 ticks (integer)
2193 ticks (Long)
(Repeated runs get close to the same)...
Drew
-----Original Message-----
From: Brett Barabash [mailto:BBarabash at tappeconstruction.com]
Sent: Wednesday, May 18, 2005 12:50 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Long vs. Integer WAS: Global Variables
> Either way, using an Integer is much slower then a Long Integer.
Much slower? I don't think so. I came up with the following test,
expecting to see a slight lag using integers instead of long integers.
The results, however, were quite surprising:
'*** BEGIN MODULE CODE
Option Compare Database
Option Explicit
Private Declare Function GetTickCount Lib "kernel32" () As Long
Public Sub Test16Bit()
Dim lngTimerStart As Long
Dim intArray() As Integer
Dim intIdx As Integer
Dim intValCtr As Integer
lngTimerStart = GetTickCount()
ReDim intArray(0 To 10000)
For intValCtr = 0 To 10000
For intIdx = 0 To 10000
intArray(intIdx) = intArray(intIdx) + 1
Next intIdx
Next intValCtr
Debug.Print GetTickCount() - lngTimerStart
End Sub
Public Sub Test32Bit()
Dim lngTimerStart As Long
Dim lngArray() As Long
Dim lngIdx As Long
Dim lngValCtr As Long
lngTimerStart = GetTickCount()
ReDim lngArray(0 To 10000)
For lngValCtr = 0 To 10000
For lngIdx = 0 To 10000
lngArray(lngIdx) = lngArray(lngIdx) + 1
Next lngIdx
Next lngValCtr
Debug.Print GetTickCount() - lngTimerStart
End Sub
'*** END MODULE CODE
I entered the code into an Access 2000 module, and ran the tests on a
3GHz P4. Here is what I came up with:
Test16Bit
4531
Test32Bit
8547
Performing math on the long integers took almost TWICE as much time than
the integers! Anyone care to comment?
(BTW, other tests I ran resulted in integers being around 200 ms slower
than long integers after 100 million iterations. Still not "much
slower")
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
DWUTKA at marlow.com
Sent: Wednesday, May 18, 2005 11:39 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Global Variable
LOL. Well, I did say that exceed
ng an Integer is possible, but that
was a philosophical point. It could exceed 32k, in your example, if you
decided to include an extended family tree. Either way, using an Integer
is much slower then a Long Integer.
Drew
-----Original Message-----
From: Scott Marcus [mailto:marcus at tsstech.com]
Sent: Wednesday, May 18, 2005 7:41 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Global Variable
<< Declaring a variables an Integer IS bad practice. It is bad practice
because even if you think a variable will never go over 32k, or below
-32k, it can, and probably will.
Question: So when will the following declaration exceed the 32k, -32k
limit?
Dim intFamilyMembers as integer 'Number of immediate family members
Answer: When you declare the variable as a Public (global) variable,
then some other function written by some other developer changes its
intended use causing the original function to possibly work incorrectly.
Scott Marcus
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
DWUTKA at marlow.com
Sent: Tuesday, May 17, 2005 7:05 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Global Variable
I guess I'm not seeing the same definition from John, though it was
closer in the last few posts. Yes, 'bad practice' sends me into a tail
spin, when there is no reason for calling something bad practice.
Declaring a variable as an Integer IS bad practice. It is bad practice
because even if you think a variable will never go over 32k, or below
-32k, it can, and probably will.
But more importantly, an Integer is a 16 bit variable, and it takes
longer to process an Integer then it does a Long Integer, on a 32 bit
system.
The
first reason is a philosophy. The second reason is a FACT!
I have yet to hear a fact, as to why Globals are 'bad practice'. What
gets my goat, though, is that this is a forum where developers of all
skill level meet. If opini
could be hampered by prejudice. Ever run into an
IT shop that refuses to allow applications to be developed in Access,
because 'it's not a database', or 'it's not secure', or something else,
that is just ignorance repeated through 'tribal knowledge'? (There is
also usually power involved...and IT shop has more power and control
involved when something is on a server side db.) That's why I rail on
this stuff, because invalid tribal knowledge can be dangerous!
Drew
-----Original Message-----
From: Francisco Tapia [mailto:fhtapia at gmail.com]
Sent: Tuesday, May 17, 2005 5:44 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Global Variable
How right you are Charlotte!, This whole thread I hear the same
definition from both John and Drew... One should take caution while
using global (public variables), Except John said the immortal words of
"Bad Programming Practice" wich for some reason seems to send Drew in a
spin. He repeats John's definition but just omit's the "Bad Programming
Practice" phrase.
Drew, there are a lot of things people can do w/ code, hundres of
variations
and they can all arrive to the same final solution, however I do believe
that there are certain procedures deemed as bad programming practice as
a principal. And rules are made to be broken. I've been working so much
more in Sql Server now-a-days and some of the common things that are bad
programming practice there are such taboo tid-bits like cursors and
dynamic sql. This same type of argument seems to ignite holly wars
between bounder-like devils and unbouder-like crusaders ;). It really is
amazing to find the various ways to accomplish something. Public
(global) variables are
yet another tool in our quest for solutions. John's point of view (if
i'm interpreting it correctly) is that in general try not to treat
Public(global) variables like a hammer...
otherwise everything will just look like a nail.
and speaking of .. this whole thread has been beaten to death
On 5/17/05, Charlotte Foust <cfoust at infostatsystems.com> wrote:
>
> LOL. And for an encore, should I demonstrate proving ANOTHER negative
> like why you didn't prove anything??? <g>
>
> Charlotte Foust
>
>
> -----Original Message-----
> From: DWUTKA at marlow.com [mailto:DWUTKA at marlow.com]
> Sent: Tuesday, May 17, 2005 1:53 PM
> To: accessd at databaseadvisors.com
> Subject: RE: [AccessD] Global Variable
>
> LOL. Well Charlotte. Give me a valid reason. I think I have proven
> all of the current ones incorrect. If you don't think so, which ones?
>
> Drew
>
> -----Original Message-----
> From: Charlotte Foust [mailto:cfoust at infostatsystems.com]
> Sent: Tuesday, May 17, 2005 3:34 PM
> To: Access Developers discussion and problem solving
> Subject: RE: [AccessD] Global Variable
>
> Give it up, John. When Drew decides no one elses arguments make any
> sense, there's no reasoning with him. ;->
>
> Charlotte Foust
>
> -----Original Message-----
> From: John W. Colby [mailto:jwcolby at colbyconsulting.com]
> Sent: Tuesday, May 17, 2005 1:06 PM
> To: 'Access Developers discussion and problem solving'
> Subject: RE: [AccessD] Global Variable
>
> ROTFL.
>
> John W. Colby
> www.ColbyConsulting.com <http://www.ColbyConsulting.com>
>
> Contribute your unused CPU cycles to a good cause:
> http://folding.stanford.edu/
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
> DWUTKA at marlow.com
> Sent: Tuesday, May 17, 2005 3:58 PM
> To: accessd at databaseadvisors.com
> Subject: RE: [AccessD] Global Variable
>
> You have said that using Globals is bad practice, which it is not.
That
> is my argument. The misuse is. 'Getting carried away with'...well,
> that's an iffy statement, because you have to judge what is 'getting
> carried away with' and what is not.
>
> Drew
>
> -----Original Message-----
> From: John W. Colby [mailto:jwcolby at colbyconsulting.com]
> Sent: Tuesday, May 17,
and problem solving'
> Subject: RE: [AccessD] Global Variable
>
> Would "getting carried away with globals" be considered misuse of
> globals? If you look back to the first post you see that is what I
> warned against. Notice I did NOT tell him that in his particular case
he
> should not use a global.
>
> YOU have built an argument for your own amusement, but in the end it
has
> enabled us to discuss the issue which is a good thing.
>
> John W. Colby
> www.ColbyConsulting.com <http://www.ColbyConsulting.com>
>
> Contribute your unused CPU cycles to a good cause:
> http://folding.stanford.edu/
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
> DWUTKA at marlow.com
> Sent: Tuesday, May 17, 2005 2:40 PM
> To: accessd at databaseadvisors.com
> Subject: RE: [AccessD] Global Variable
>
> Ah. There's the issue. 'If a global doesn't need to be SET by project
> wide code'. Okay. Now, that I will back down on. I personally don't
> have an issue with setting it one place, and using it other places. No
> problem there. But what if you are constantly using (reading and
> writing) it from many places in your project. Does a Global Variable
> fit the model? Of course! Honestly, I use classes too, and will make
> read only properties 'read only'.
>
> Drew
>
> P.S.-- Still doesn't make Globals bad practice, only misuse of
> globals...which is still my position.
>
> -----Original Message-----
> From: John W. Colby [mailto:jwcolby at colbyconsulting.com]
> Sent: Tuesday, May 17, 2005 11:52 AM
> To: 'Access Developers discussion and problem solving'
> Subject: RE: [AccessD] Global Variable
>
> I understand completely Drew. In order to not use globals you have to
> THINK and you are too busy typing to do that.
>
> Correct me if I am wrong, but nowhere did I advocate any code like you
> mentioned. Can you show me where in my email I advocated that? What I
> said was that if a global doesn't need
d to be global.
>
> I have seen in your previous posts where you mention saving
keystrokes.
> Understand that I am NOT a data entry person. My job is to design well
> engineered systems. If that means more keystrokes, so be it.
>
> John W. Colby
> www.ColbyConsulting.com <http://www.ColbyConsulting.com>
>
> Contribute your unused CPU cycles to a good cause:
> http://folding.stanford.edu/
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
> DWUTKA at marlow.com
> Sent: Tuesday, May 17, 2005 11:32 AM
> To: accessd at databaseadvisors.com
> Subject: RE: [AccessD] Global Variable
>
> Tighter? If I looked at code like this:
>
> Dim MyModuleLevelString as String
> Private Function SetModuleLevelString(strValueToSet As String)
> MyModuleLevelString=strValueToSet End Function
>
> I would think the developer was getting paid by the key stroke.....not
> that it was 'tight code'.
>
> Drew
>
> -----Original Message-----
> From: John W. Colby [mailto:jwcolby at colbyconsulting.com]
> Sent: Tuesday, May 17, 2005 6:59 AM
> To: 'Access Developers discussion and problem solving'
> Subject: RE: [AccessD] Global Variable
>
> Gustav,
>
> This is nothing new, and not something I take credit for figuring out.
> It is not uncommon when you work with classes to have methods set the
> values of and return the values from class properties. In fact with
> classes you have syntax constructs specifically for this - property
> get/set/let. You can, if you wish, dim a variable public in the class
> header and then it is just read / write to anyone with a pointer to
the
> class. Or you use a property get and or set/let in whatever
combination
> you need. A read-only value has only a property get. A Write-only has
> only a property set (not very common) and a read / write has a
property
> get and property let/set.
>
> The objective is simply to control how the variable is read/written.
> Since the variab
o the module (or class),
only
> a function in the module or class can set the value, and only a
function
> in the module or class can return the value. To make a property "read
> only", create only a function that returns the value, but do not build
a
> function that sets the value. Then only the class or module itself can
> set the variable.
>
> For example as the module initializes, perhaps some value is pulled
from
> a table and written into the variable. Then a function returns the
> value to any process that needs the value. Or perhaps the value is
> calculated by some math transformation using other values in other
> variables. The other variables are set by processes, but in order to
> read out the value, a function either returns the variable directly or
> returns the value of the mathematical transformation using the values
in
> the other variables.
>
> This is not new stuff, I did not invent it, but it is commonly used to
> "replace" global variables such that the CONCEPT of a global variable
> exists (can be seen from anywhere) but still protects the variable
from
> being written when it shouldn't be or by processes that should not be
> able to write to the variable.
>
> And yes, it is more work. It is just one of those things that you do
or
> your don't. If you accept the practice, then you start thinking about
> protecting variables, using variable scope, and using functions to set
/
> return values where appropriate. It becomes habit and your code
becomes
> a little bit tighter.
>
> John W. Colby
> www.ColbyConsulting.com <http://www.ColbyConsulting.com>
>
> Contribute your unused CPU cycles to a good cause:
> http://folding.stanford.edu/
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav
Brock
> Sent: Tuesday, May 17, 2005 6:30 AM
> To: accessd at databaseadvisors.com
> Subject: RE: [AccessD] Global Variable
>
> Hi John
>
> Well, here we have full co
ingers.
>
> I haven't managed yet to build self generating code; to some this
would
> indicate a brave new world, to some it would be a nightmare -
functions
> creeping around and attacking our globals and eating our children...
> gosh. But worse, they would soon learn how to take advantage of your
> functions to change those "private variables"! Be prepared.
>
> /gustav
>
> >>> jwcolby at colbyconsulting.com 05/16 10:58 pm >>>
>
> .. Making this a global allows functions
> that have no business setting these variables to change them. By
having
> a private variable returned by a public function, any function that
> needs the information can get it but cannot modify it.
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> --
> AccessD mailing list
> Ac
sD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
--
-Francisco
http://pcthis.blogspot.com |PC news with out the jargon!
http://sqlthis.blogspot.com | Tsql and More...
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
----------------------------------------------------------------------------
----------------------------------------
The information in this email may contain confidential information that
is legally privileged. The information is only for the use of the intended
recipient(s) named above. If you are not the intended recipient(s), you
are hereby notified that any disclosure, copying, distribution, or the
taking
of any action in regard to the content of this email is strictly prohibited.
If
transmission is incorrect, unclear, or incomplete, please notify the sender
immediately. The authorized recipient(s) of this information is/are
prohibited
from disclosing this information to any other party and is/are required to
destroy the information after its stated need has been fulfilled.
Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of Tappe Construction Co.
This footer also confirms that this email message has been scanned
for the presence of computer viruses.Scanning of this message and
addition of this footer is
onjunction with virus detection software.
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com