[AccessD] ReadDirectoryChangesW, not returning anything to t hebuffer.

Bobby Heid bheid at appdevgrp.com
Thu Sep 11 12:32:11 CDT 2003


I agree that longs used on a 32-bit processor are more efficient.  These
processors' word size is 32-bits, so a 16-bit integer has to undergo a
conversion to long for the processor to use it and a conversion back to an
integer when the processor is finished with it (assuming it is storing the
value somewhere).  

I also think that with today's processors that it really doesn't matter
which one you use unless you are using integer math in some sort of
numerical algorithm.

I did a quick and dirty benchmark that used two loops with long variables as
the counter to do some integer and long math (averaged over 5 runs) and it
looks like the code using the longs is about 10% faster than the integer
code.  Note that this was ran in Win2k with Acc97 (I know, I know...) with
e-mail and other stuff running in the background.

Here is my code and the output of it.  
(Please, no comments on variable names and the like - LOL.)

Public Sub testtime()
Dim y    As Long
Dim j    As Long
Dim x    As Long
Dim k    As Integer
Dim kk   As Integer
Dim m    As Long
Dim mm   As Long
Dim t(3) As Date
Dim avg1 As Single
Dim avg2 As Single


   kk = 5
   mm = 5
   j = 100000000
   avg1 = 0#
   avg2 = 0#
   
   For y = 1 To 5
      
      t(0) = Now()
      For x = 1 To j
         k = kk + 1
         k = kk - 1
         Next x
      t(1) = Now()
   
      t(2) = Now()
      For x = 1 To j
         m = mm + 1
         m = mm - 1
         Next x
      t(3) = Now()
      
      Debug.Print "Run #"; y, "count="; Format$(j, "#,##0")
      Debug.Print "Loop 1 (integer): "; "t(0)="; Format$(t(0), "hh:nn:ss");
"   t(1)="; Format$(t(1), "hh:nn:ss"); _
         "   diff="; DateDiff("s", t(0), t(1)); " seconds"
      Debug.Print "Loop 2: (long)  : "; "t(2)="; Format$(t(2), "hh:nn:ss");
"   t(3)="; Format$(t(3), "hh:nn:ss"); _
         "   diff="; DateDiff("s", t(2), t(3)); " seconds"
      Debug.Print
      
      avg1 = avg1 + CSng(DateDiff("s", t(0), t(1)))
      avg2 = avg2 + CSng(DateDiff("s", t(2), t(3)))
      
      Next y
      
   avg1 = avg1 / 5#
   avg2 = avg2 / 5#
   
   Debug.Print "Average for integers:  "; avg1; " seconds"
   Debug.Print "Average for longs:     "; avg2; " seconds"
   

End Sub


Here's the output:
testtime
Run # 1       count=100,000,000
Loop 1 (integer): t(0)=13:21:47   t(1)=13:22:10   diff= 23  seconds
Loop 2: (long)  : t(2)=13:22:10   t(3)=13:22:30   diff= 20  seconds

Run # 2       count=100,000,000
Loop 1 (integer): t(0)=13:22:30   t(1)=13:22:53   diff= 23  seconds
Loop 2: (long)  : t(2)=13:22:53   t(3)=13:23:13   diff= 20  seconds

Run # 3       count=100,000,000
Loop 1 (integer): t(0)=13:23:13   t(1)=13:23:36   diff= 23  seconds
Loop 2: (long)  : t(2)=13:23:36   t(3)=13:23:56   diff= 20  seconds

Run # 4       count=100,000,000
Loop 1 (integer): t(0)=13:23:56   t(1)=13:24:19   diff= 23  seconds
Loop 2: (long)  : t(2)=13:24:19   t(3)=13:24:39   diff= 20  seconds

Run # 5       count=100,000,000
Loop 1 (integer): t(0)=13:24:39   t(1)=13:25:02   diff= 23  seconds
Loop 2: (long)  : t(2)=13:25:02   t(3)=13:25:22   diff= 20  seconds

Average for integers:   23  seconds
Average for longs:      20  seconds


Bobby

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Henry Simpson
Sent: Thursday, September 11, 2003 11:56 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] ReadDirectoryChangesW, not returning anything to t
hebuffer.


The manner in which a form or report open event cancel parameter appears to 
operate is as a boolean. Passing in a zero permits the object to open and a 
non zero numeric cancels the opening.  Microsoft declares this parameter as 
an Integer likely because the boolean datatype was added to the VBA language

after the Cancel parameter was first created and was left in place for 
backward compatibility.  In fact the compatiblity goes back to the 16 bit 
versions of Access so we continue to see this kind of anomaly.  Why 
something as fundamental to the OS as mouse location parameters, where 
events fire many times per second, are still singles (and integer for the 
button parameters) is less defensible if longs are measurably more 
effiicient than other datatypes.

I did a little test with the cancel parameter in a form.  I dimensioned a 
long variable and set it to zero and set the cancel paramter to the long and

the form opened witout error.  When I set the variable to 64,000 the open 
event cancelled and when I tried 200,000, an out of range error was raised 
rather than a data type error.  This suggests to me that there was an 
attempt to coerce a datatype conversion on the Long variable to match the 
integer type of the cancel parameter before passing to the procedure.  If 
you are using a long variable to a procedure expecting an integer, then the 
probable sequence of events is:

Parameter type demotion
Pass to procedure
Conversion to Long by OS for CPU manipulation

whereas if you begin with an integer type rather than a boolean or a long, 
you skip the first type conversion and perhaps the procedure runs a few 
picoseconds faster.

While this is hardly proof of the issue it renders your assertion that longs

are always faster suspect.  I made a post earlier this week that I generally

use longs given a choice because they are inherently faster in a 32 bit 
environment and that is the basis of my 'preference' but I also believe it 
is better to play safe and match the datatypes of a procedure defined by 
Microsoft developers.  Better and perhaps also faster.

Hen

>From: Drew Wutka <DWUTKA at marlow.com>
>Reply-To: Access Developers discussion and problem
>solving<accessd at databaseadvisors.com>
>To: "'accessd at databaseadvisors.com '" <accessd at databaseadvisors.com>
>Subject: RE: [AccessD] ReadDirectoryChangesW, not returning anything to t 
>he buffer.
>Date: Wed, 10 Sep 2003 23:18:46 -0500
>
>It shouldn't even be a preference.  Longs are faster in a 32 bit 
>system, so unless it's absolutely necessary to use an Integer (API 
>Calls), there is really no reason to use an Integer.
>
>Drew
>
>-----Original Message-----
>From: Henry Simpson
>To: accessd at databaseadvisors.com
>Sent: 9/10/03 11:09 PM
>Subject: RE: [AccessD] ReadDirectoryChangesW, not returning anything to 
>t
>he
>buffer.
>
>Odd.  Although I have a preference for longs myself, it turns out that 
>a
>
>number of standard Access functions use other numeric types so there is 
>little need to look for old API calls to run into these.  For example, 
>the mouse cooridinate parameters in a mouse move, down or up event are
>singles
>even though the values are always 'whole' numbers while the button and
>shift
>parameters are integer types.  The standard cancel parameter for open
>events
>is also typed as an integer and you had better dimension a compatible
>numeric type if you are passing a value to one of these standard
>procedures
>as a variable, though the mouse parameters are technically return or
>read
>only values 'returned' by a sub procedure.  My rule is to use a
>compatible
>type and if a long will work, that's the ticket.
>
>Hen
>
>
>
> >From: Drew Wutka <DWUTKA at marlow.com>
> >Reply-To: Access Developers discussion and problem 
> >solving<accessd at databaseadvisors.com>
> >To: "'Access Developers discussion and problem solving'" 
> ><accessd at databaseadvisors.com>
> >Subject: RE: [AccessD]  ReadDirectoryChangesW, not returning anything
>to t
> >he buffer.
> >Date: Wed, 10 Sep 2003 18:05:01 -0500
> >
> >LOL.  Very funny.
> >
> >I do use int for all integers, because I always dimension as Long,
>unless I
> >absolutely require an integer (which is only for API calls)
> >
> >Drew
>
>_________________________________________________________________
>The new MSN 8: smart spam protection and 2 months FREE* 
>http://join.msn.com/?page=features/junkmail
>
>_______________________________________________
>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

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*   
http://join.msn.com/?page=features/junkmail

_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



More information about the AccessD mailing list