|
| Discussion | |
From: mda
Keywords: XFormDBF, Suggestion
Remote Name: 24.147.232.222
Remote User:
Date: 02/08/01
Time: 15:03
1. delayed instantiation
I think this is probably much more of an issue for BTCrit than it is for XFormDBF. I'll take your word for it that it's a big annoyance in BTCrit. I haven't found instantiation to be a major problem in my testing of XFormDBF, even with lots of mappings, so I don't personally regard this as a high priority. Also, if the user is going to go to the fields page anyway, you're not doing them much of a favor by delaying its instantiation. The argument for delaying instantiation in BTCrit is much more compelling, however, since it has lots of fat pages that a user is unlikely to go to, and this instantiation represents most of the entire cost of running BTCrit. For XFormDBF, the most important optimizations will be those that bear on the speed of actually running the transformations, especially as the number of records, fields, and mapping complexity increase. So I think it's unlike we would address the delayed instantiation issue before making further efforts to optimize Run performance (xfma0049), and many other tasks would probably be regarded as more important, too.
2. avoiding instantiation for non-interactive Runs
Again, this is much more obviously justified in BTCrit than XFormDBF, where it's not clear it's worth the extra programming effort for the amount to be gained. Certainly it can be done, and there will be at least a small, fixed improvement, but we need to put the question of XFormDBF optimization into proper perspective. That's why I encouraged you to create some sample standalone test configurations in your XFormDBFTest directory, so I can review some of the more important real-world examples of known problem cases, without any irrelevant Job Control complications. Once we have some real examples of important transformations to be sped up, we can look at all of the options and see which changes are likely to have the greatest impact, and we can benchmark the results to prove it. I wouldn't turn the problem around and assume a particular solution before the problem is adequately defined. So please, follow my suggestion and create some good standalone test configurations. Then we can really take a serious look at optimization.
3. don't save state in non-interactive Runs
This is already how XFormDBF behaves, accomplished by logic in Init that clears the functionid (this.svp_funcid) for non-interactive (not this.ehp_interactive) modes.
|
|
|
|
| Contents | Discussion | |
|