[AccessD] Cost of Debug.Print Statements

Hi Arthur,
Don't know if you have had a response to this but I have something similar
on my system but what it does is to write a line to say it had entered a
function/sub and again when it left so that I could track where bottlenecks
were or areas for improvement, how long it was in the function, etc.  

It was turned on/off from a button on a form.  The output was written to a
table and could be viewed from a form.

Because it was writing records it would, I think, be a bit slower then
writing a debug.print statement but the overall impact was very noticeable
when it was on/off.

HTH

Max


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: 08 August 2009 13:59
To: Access Developers discussion and problem solving
Subject: [AccessD] Cost of Debug.Print Statements

Almost all of my proven, reusable code uses a constant to encase Debug.Print
statements in If/EndIf. But typically in the actual application code I just
plonk in Debug.Print statements so that I can see what's going on during
development. But suddenly I'm curious as to the overall impact on
performance. How much does a Debug.Print statement cost you?
And while we're on the subject, in all my years of coding Access, I have
never once used Debug.Assert. I would assume that it works like the Assert
statement in other languages I've used. Does anyone use it and if so when
and where?

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