Re: BTCrit saving and restoration mechanism - speedups

From: mda
Keywords: Saver, Enhancement, Suggestion
Remote Name: 24.147.233.252
Remote User:
Date: 08/22/00
Time: 12:43

Comments

The typical BTCrit configuration probably uses only a small fraction of the large number of available criteria, so you should be able to speed up both state-saving and restoration by skipping over criteria that are already at their default settings, as you suggest.  In order to make this approach work, you would need to adjust the state-saving logic to cause the first restoration step to be putting the whole form into its default state, which would presumably be a new method of the form.  State-saving logic for individual criteria would then be turned into no-ops for cases where they are in their default state, so you avoid both the cost of generating a meta-file record and the cost of executing it upon state restoration.  This also would make saved configurations more compact.  As a further optimization, the method for defaulting the whole form could also check for the special case of criteria being already in their default state, but this is probably a much more minor optimization.

In addition to the above, which only helps if most aspects of the configuration tend to be left in their default state, keep in mind the following potential optimizations:

use form.LockScreen during state restoration

Setting LockScreen = .t. temporarily as one of the first state restoration steps can speed things up quite a bit, by reducing the klunky intermediate screen repainting that occurs otherwise.  (This is especially noticeable when the application is used via remote control such as pcANYWHERE.)  The final step of state restoration would be to turn off the LockScreen property.

use Commander's literal string assignment syntax when appropriate

If you are saving a character string property, it should be more efficient to use the special Commander syntax that avoids the more costly &-macro command line expansion to execute a state-restoration step.  The literal string assignment syntax also avoids problems with special character and long strings.

I'm currently working on a new version of the Saver facilities that will reduce the size and complexity of state-restoration commands somewhat, but I don't expect this to have a major impact on performance.  The primary motivation for the upcoming Saver changes is to support better error handling, as well as a generally cleaner design.  As you mentioned, it will be necessary to update your saved configurations after making the changes you are contemplating.  Making it easier to to automatically convert old configuratons easier is another issue I'd like to tackle in the new version of the Saver facility.

Brought to you by SpaceTime Systems.  All rights reserved.