Jim Dettman
jimdettman at verizon.net
Mon Feb 19 09:18:29 CST 2007
John, <<Late binding performs the LOOKUP of all the data about the object at RUN TIME, but more specifically at the instant that the SET statement is executed. >> It's worse then that; it's a lookup at every property or method call to the object. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of JWColby Sent: Monday, February 19, 2007 10:06 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Missing references As I attempted to explain in my earlier discourse on binding, using an "as object" syntax is late binding. The IMPACT of late binding is not as simple as "the code is loaded" but rather is determined by a myriad of things, but you can essentially boil it down to "how often is the set statement encountered". Early binding performs the LOOKUP of all the data about the object at COMPILE TIME. Thus there is NO IMPACT at run time, all the lookup of the object information has already been done. Late binding performs the LOOKUP of all the data about the object at RUN TIME, but more specifically at the instant that the SET statement is executed. Late binding will ALWAYS have some impact (assuming that the set statement is run) because the lookup must occur. I make the disclaimer "assuming the set statement is run" simply because, for example. I could have an EXCEL class or module in my project. It matters not whether it is in the FE or out in a library, what matter is, whether any code ever tries to ACTUALLY EXECUTE a SET STATEMENT to set a variable dimensioned as object. Thus one of my users may use the application for days and weeks and never experience the impact of late binding because his job never entails using that EXCEL code. Another user may experience the impact of late binding all day every day because his job requires using the code that executes the set statement, i.e. he uses Excel and I am late binding excel objects. NOW... How severe is the impact for that user? It may be very little or it may be extreme. What determines the impact to this user is HOW OFTEN the set statement is executed, how LONG does it take to perform the binding, and what % of the total code execution time is taken up by the binding. Let's take an example. The code does nothing more than load excel and open a worksheet. That would be at least two objects late bound, the Excel Application, and the worksheet. The time to bind the object that holds the pointer to Excel is completely DWARFED by the time to actually load Excel off the disk. We are talking a few milliseconds to do the binding and probably seconds to load excel. So the user would never even feel the difference between early and late binding. The same goes for loading the spreadsheet itself. Again, the binding itself takes a few milliseconds, but loading the worksheet would take a second or two. The user would never even feel the difference. Take another example however. This user has to load a spreadsheet, and the code is going to load and manipulate 10 thousand cells, placing data, formatting it, setting up formulas etc. NOW the time to reference each cell may take a few milliseconds but the time to actually manipulate the cells might well be sub-millisecond. So late binding in this case could slow down the app by orders of magnitude. It could do the whole thing in a second if early bound but take 10 seconds, 100 seconds etc if late bound. The DIFFERENCE is simply that the time to do the binding is occurring thousands or tens of thousands of times as the program manipulates the contents of the spreadsheet. Suddenly milliseconds start to add up. As you can see, this is a complex subject and one where the answer "is late binding costing me much" changes radically depending on what the code is doing. And it really has nothing to do with when it is loaded and whether it is sitting in memory. It is all about how many times the set statements execute, and how much of the total time those set statements use. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of artful at rogers.com Sent: Monday, February 19, 2007 9:26 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Missing references You may be right, but it flies in the face of what little I know about Access. I was under the impression that code sitting in the MDB would be loaded on first call and thereafter reside in memory. Is that not true when you do something like create a Word object? Arthur Fuller Technical Writer, Data Modeler, SQL Sensei Artful Databases Organization www.artfulsoftware.com ----- Original Message ---- From: Jim Dettman <jimdettman at verizon.net> To: Access Developers discussion and problem solving <accessd at databaseadvisors.com> Sent: Monday, February 19, 2007 8:41:07 AM Subject: Re: [AccessD] Missing references Jim, <<By checking the local references a program can then adapt to its' current surroundings; but this requires a late-binding design.>> How so? If your dimming something as an object, you using late binding. I don't know of anyway of changing from late to early without re-compiling the program. And if you use late binding, your carrying the performance hit all the time. Jim. -- 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