Early & Late Binding

No problems here Pat.

I think you have hit the nail on the head when you refer to tight looping.

To me it makes no sense to have a command button initiate short high-speed single pass code. The processor has done billions of cycles while just waiting for the user to push the button then, all of a sudden, the user wants an instant response. Hey, if they want the code to finish earlier they should have pushed the button sooner. Taking two seconds to push the button and wanting the result 5 microseconds sooner doesn’t seem quite right to me. In this case I prefer easily read source code. The . usually has the advantage of IntelliSense, if that is what it is called, and for me that is sufficient reason to use it in these circumstances.

But when we get into a multi-pass tight loop, things start to change. In this case I prefer tight fast code and readability can go out the window. Therefore, as you say, it helps to know which is the fastest way to do things because then we have a choice.

But to know which is fastest it must be timed and it must be timed in a realistic manner.

As I said previously I’m not a great fan of extrapolating a single pass to the many in a loop nor to interpolate loop time back to the single pass. Too many variables arise and one did during testing.

In the version 1 demo I attached, don’t know if you downloaded it, the time to initially update 400 controls was about 420 milliseconds. Not too bad considering there aren’t that many Forms with four hundred text boxes.

But if you take any one of the 6 Forms and create a command button that calls the update routine, it takes about 7,500 to 10,000 milliseconds to run the update and the timing is all over the shop. This represents a 20:1 timing decay not the trivial 5% in the looping tests.

Why? I don’t hear you ask! And I’m glad I don’t hear you ask because I have absolutely no answer at this stage.

It still needs more testing and the more people to test it the better.

Regards,
Chris.
 
Last edited:
G’day all.

Looks like the timing of control update is far more dependent, not on the method of update, but whether or not the control in visible.

Not the outcome I expected. :eek: :D

New demo attached.

Regards,
Chris.
 

Attachments

G'day all.

This one removes the screen flicker by not using the Form Visible property but turning off screen Echo during the update.

Version 3 attached.

Regards,
Chris.
 

Attachments

Last edited:
Chris,

Great job. The first set of stats, to me, showed that
regardless of reference method, there isn't a "drastic"
performance hit in choosing coding styles.

But your last DB. Why on Earth would something update
that much quicker just because it was invisible? The
magnitude of that difference is very noticable.

In my old VAX days, any sort of I/O device (disk, video,
or whatever) was WAY slower than the CPU. They had two
kinds:

QIO - Send and go on with current code.
QIOW - Send and wait for an acknowledgement

I figured Access was spending the extra time updating
the controls on the Screen. I had the logic as follows:

Access updates the control in memory, which takes
one unit of time.

If the control is invisible, it's done.

Otherwise the amount of time to ship something out to
the video card, display it, (and I think) wait for an
acknowledgement takes 20 units of time.

I went into your Form1 to cut it by half the controls
and the stats stayed consistent.

BUT, during all of that time waiting for the "visible"
update, the display doesn't change! All controls are
updated only at the end of that subroutine. I expected
to see the changed controls snaking their way down the
screen, but no. I even tucked a little Me.Refresh after
a couple of early ones, but no luck.

This isn't what I expected. I'll take a look again in
a little while.

Wayne
 
Thanks Wayne and it is a bit of an eye opener.

As to why it is so much faster seems entirely due to the screen update time even though the screen doesn’t appear to update. :confused: The same sort of timing difference occurs if the Form is invisible or screen echo is off.

I too would have expected to see the controls snaking but it may be due to the fact they are all bound to the same field. I tried requering each control after it was updated with/without a doevents but still no snake, just an increase in screen flicker and execution time.

Would be nice to see the snake because if we have to wait so long we would at least have something to watch. :rolleyes:

Might have a bit more of a play with it. :D

Regards,
Chris.
 
Well we can snake the back colour but the first doevents seems to requery all text boxes.

Version 4 attached.

Regards,
Chris.
 

Attachments

Chris,

I made the controls unbound and got an amazing increase
in speed. This is not a display issue (i.e. the display method
is not twenty times slower.

Unbound Visible = 125
Unbound Invisible = 93

Now it doesn't make sense that "bound" controls have a
wide time descrepancy with respect to their visibility.

"Unbound" controls evidently do not.

More research ...

Wayne
 
Good point,

Could be a combination of Bound and Visible.

Yep…more research.

Regards,
Chris.
 
The "re" Methods

Refresh Method - Use the Refresh method to immediately update the records in the underlying record source for a specified form or datasheet to reflect changes made to the data by you and other users in a multiuser environment. The Refresh method shows ONLY changes that have been made to the current set of records; it doesn't reflect new records or deleted records in the record source.

Requery Method - Use the Requery method to update the data underlying a form or control to reflect records that are new to or have been deleted from the record source since it was last requeried.
If you want to requery a control that isn't on the active object, you must use this method, not the Requery action or its corresponding DoCmd.Requery method.

Repaint Method - The Repaint method completes any pending screen updates for a specified form. When performed on a form, the Repaint method also completes any pending recalculations of the form's controls.

Recalc Method - immediately updates all calculated controls on a form. Using this method is equivalent to pressing the F9 key when a form has the focus. You can use this method to recalculate the values of controls that depend on other fields for which the contents may have changed.
 
Thanks Pat.

400 Bound Controls.
Me.Refresh method.
Echo On 397,632 milliseconds
Echo Off 118,521 milliseconds

Version 5 attached.

Versions 6, 7 and 8 coming up.

Regards,
Chris.
 

Attachments

Thanks Pat.

400 Bound Controls.
Me.Text0.Requery method.
Echo On 8,913 milliseconds
Echo Off 680 milliseconds

Version 6 attached.

Versions 7 and 8 coming up.

Regards,
Chris.
 

Attachments

Thanks Pat.

400 Bound Controls.
Me.Repaint method.
Echo On 10,455 milliseconds
Echo Off 360 milliseconds

Version 7 attached.

Versions 8 coming up.

Regards,
Chris.
 

Attachments

Thanks Pat.

400 Bound Controls.
Me.Recalc method.
Echo On 550,812 milliseconds
Echo Off 118,390 milliseconds

Version 8 attached.

Regards,
Chris.
 

Attachments

G’day all.

At this point in time (pun intended) the fastest is Version 3 for bound Controls, but that could change.

The fastest method so far was mentioned by Wayne…
Keep the Controls unbound AND (invisible IOR Echo Off).

But if controls are unbound and still require writing their data back to a table then where will be and additional overhead in time. How much...I don't know.

Two things seem certain...
The method of writing data to a control is immaterial, and all timing needs to be timed.

Regards,
Chris.
 
G’day all.

While I’m in the mood for writing something, whether or not it is important I must leave up to you, here is a link to something that may help. Sorry if you have read it before, but the first paragraph says what I think.

We can talk about the theory of timing all day long but, in the end, we must go for the demonstrated facts.

Anyone want to add an alternative method, proven or otherwise, to the discussion?

Regards,
Chris.
 
I'd like to add something...

Access still sucks whether you're giving me 100 seconds or 1000 seconds, it's still dirt slow. You can take that to the bank!!!

Jon

:D
 
ChrisO said:
Thanks Pat.

400 Bound Controls.
Me.Recalc method.
Echo On 550,812 milliseconds
Echo Off 118,390 milliseconds

Version 8 attached.

Regards,
Chris.

Heh do you have a life ?:D :D
 
Heh do you have a life ? :D :D

Version 8 took longer to run than it took to write. :(

Regards,
Chris.
 
G’day all.

OK, almost everyone seems to be getting a bit bored with timing their assumptions.

Apart from Wayne Ryan and myself, nobody has posted their own “test results”.

Would all others prefer to live with their assumptions or do the ‘hard yards’ to prove them?

Seems simple to me; postulate or prove.

Sound tough? Yes it is, but we are in a tough environment.

If you wish to modify the source code then look at this.
In version 3 the line was: -

strSub = strSub & vbNewLine & vbTab & strTemp

In version 8 it looked like this: -

strSub = strSub & vbNewLine & vbTab & strTemp & _
vbNewLine & vbTab & "Me.ReCalc"

Anybody, and that means anybody, that wishes to have their say and pontificate, ought to be brought into question.

Would it not be beneficial to know the facts or simply play with our own imaginations?

Regards,
Chris.
 

Users who are viewing this thread

Back
Top Bottom