William Hindman
wdhindman at dejpolsystems.com
Mon Feb 19 09:48:10 CST 2007
...give me a break, eh ...my head hurts ...too much information too early for a Monday morning :( William Hindman ----- Original Message ----- From: "JWColby" <jwcolby at colbyconsulting.com> To: "'Access Developers discussion and problem solving'" <accessd at databaseadvisors.com> Sent: Monday, February 19, 2007 10:36 AM 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 >