ChrisO
Registered User.
- Local time
- Tomorrow, 04:46
- Joined
- Apr 30, 2003
- Messages
- 3,202
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.
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: