JWColby
jwcolby at colbyconsulting.com
Wed Feb 21 04:49:08 CST 2007
>My understanding is that when an object is just DIMmed space is set aside for an expected object. That is correct. 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 Jim Lawrence Sent: Wednesday, February 21, 2007 3:00 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Missing references Just a comment... My understanding is that when an object is just DIMmed space is set aside for an expected object. It is not until the SET is run that the object populated with the appropriate methods, properties, events etc. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Monday, February 19, 2007 8:51 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Missing references Jim, From what I've been told/read in the past, the set statement merely gives you a pointer to the object and its address lookup table. With late binding, VBA does not know the address of the property/method call before hand, so it must execute a GetIDsOfNames and Invoke call with each property/method it encounters at runtime. With early binding, it already knows the address, so it just needs the invoke call. 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:36 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Missing references Jim, > It's worse then that; it's a lookup at every property or method call > to the object. I don't believe so. The set statement essentially loads all that stuff into memory and is a one time affair (per execution of the set statement). I think you are thinking of the syntax dim MyObject = NEW XXX In this case the dim and the set statement have been merged into one line of code and IIRC with this syntax you are correct. However if you break it out into a separate dim and set statement: Dim MyObj as object set MyOpject = ... Then the set statement permanently loads the object information for as long as the object stays in scope. 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 Jim Dettman Sent: Monday, February 19, 2007 10:18 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Missing references 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 -- 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