[AccessD] uSecond timing

[Stuart McLachlan]

He mkes a good point for tat code.

A classic case where a Class is NOT the answer. (Sorry john :) )

The overhead of a classlike that compared to just wrapping the function in a couple of API 
calls will severely affect the accuracy of the timing process.


But that quote misses the point of using a high resoution timer.  It's when you need to repeat 
a set of instructions (either a function or just a piece of code)  many times that it matters.

Optimising parsing of lines of data read into a database from a large file with many records 
would be a prime example where it could be useful



On 3 Sep 2020 at 7:45, Gustav Brock via AccessD wrote:

> Hi John and Stuart
> 
> Here:
>  https://stackoverflow.com/a/199480/3527297
> 
> I noticed this comment, and - for most practical purposes - I think he
> has a point:
> 
> <quote>
> Still, if you're measuring performance in VBA, getting 1/100th of a
> second resolution is not bad. -- Invoking the timing calls alone could
> take a couple of ms. If the call is so fast that you need that much
> resolution to time it, you probably don't need performance data about
> that call. - BrainSlugs83 </quote>
> 
> /gustav
> 
> -----Oprindelig meddelelse-----
> Fra: AccessD <accessd-bounces at databaseadvisors.com> På vegne af Stuart
> McLachlan Sendt: 2. september 2020 23:31 Til: Access Developers
> discussion and problem solving <accessd at databaseadvisors.com> Emne:
> Re: [AccessD] uSecond timing
> 
> LongLong only works with 64bit VBA.  A lot of people are still using
> 32bit Office.
> 
> An alternative:using a UDT LongInteger
> 
> https://stackoverflow.com/questions/198409/how-do-you-test-running-tim
> e-of-vba-code
>