Re: [U2] Virtual fields calling Virtual fields
In message [EMAIL PROTECTED], Drew Henderson [EMAIL PROTECTED] writes John, Never tried to see how far it would go. The real issue is inefficiencyeach virtual field requires an additional read from the dictionary in which it is located. Doing this for every item in a report, you can see where the overhead makes chaining virtual fields inefficient. Not necessarily true. In the example John described, I think you would get badly hammered with inefficiencies. But ... if all the virtual fields are in the *same* dictionary, they get collapsed into one at compile time. Certainly I would recommend never pointing a virtual field at a virtual field in a different file, but wouldn't think twice at pointing virtual fields at each other in the same file (provided they don't use @n syntax !!!) Cheers, Wol -- Anthony W. Youngman [EMAIL PROTECTED] 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998 Visit the MaVerick web-site - http://www.maverick-dbms.org Open Source Pick --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Virtual fields calling Virtual fields
Some comments interspersed for those not comfortable with virtual fields. The primary context here is UD, but I note some differences between UV UD. Then an example. cds From: Anthony W. Youngman Certainly I would recommend never pointing a virtual field By the way, the term virtual comes from UD, not UV. I like it, because it nicely distinguishes between stored derived (real virtual, respectively). UV sticks with the old Prime Information-descriptor wording. UD allowed dictionary items as either I- V-types, synonymously; UV, I- only. at a virtual field in a different file, You can't with UV. I wish you could. I did not know UD allowed it. I don't see that as _inherently_ bad, just abusABLE. See more comments below. but wouldn't think twice at pointing virtual fields at each other in the same file Right. I encourage it. It's called REUSEABLE CODE. The only downside is a lack of a native tool for managing dictionary snippets. What I mean is, I'd like to look at a UniQuery/RetrieVe sentence, see all the dictionary items it references, including related, nested virtual fields in a way that is easy to read and maintain. The best tool I have seen for doing that is called SoftWhere, by Joe Toledo. I think Ray Jones has something, too. Others? (provided they don't use @n syntax!!!) UV imposes this restriction. If you attempt to reference an I-descriptor where the nested I-descriptor does not have multiple calculations, separated by semi-colons, it won't compile. (This is a weakness, in my opinion. Probably deep in the I-descriptor compiler and not easily changed.) Example demonstrating double translate, reusable code, @n-syntax: TOTAL.COST 01: I 02: PRICE * TAX.RATE TAX.RATE 01: I 02: TRANS( STATE.TABLE, TRANS( CUSTOMER, CUST.ID, STATE, 'X' ), TAX.RATE, 'X' ) @n-syntax: - If you are going to reference it from TOTAL.COST, this is not allowed: TAX.RATE 01: I Customer's tax rate. 02: TRANS( CUSTOMER, CUST.ID, STATE, 'X' ); TRANS( STATE.TABLE, @1, TAX.RATE, 'X' ) which is a shame, because it is more readable. Concerning efficiency in the above: -- I would not hesitate to do the above double TRANS(). TAX.TABLE is likely to be small. It is likely to be loaded into memory by a modern OS and remain there for the duration, probably even permanently cached on a busy system. If your data is sorted by customer, so that you are going after the same record repeatedly through your RetrieVe/UniQuery statement before advancing to the next, the OS will likely keep that same one cached in memory for the duration, too. Furthermore, on UV (UD, too??) TRANS() has some efficiency built in, too. If you ask TRANS() for a field from the same record as last time, it has it cached. So if your report lists CUST.NAME CUST.ADDR, CUST.PHONE, etc., for the same CUST.ID, TRANS() gets the CUSTOMER record only once. (By the way, I find on UV that I simply cannot devote too much memory to caching files. The more memory, the better. I don't know how UD compares, but for some reason, UV demands this more than our Oracle, Informix, and SQL DBs, to achieve acceptable performance. Conversely, UV leaves a smaller per-process private memory footprint.) Reusability: It is nice to define TAX.RATE once in this dictionary. Putting TAX.RATE in it's own V- or I- descriptor and referencing it from TOTAL.COST, other virtual fields, or explicitly is nice because maybe today it is a simple lookup in STATE.TABLE, but next year it might be a subroutine call to account for Canadian methods, or in 2009, after President Steve Forbes replaces US income tax with a national sales tax... Even more Reusable: -- The way it is now (in UV), every dictionary (or program) that knows a CUST.ID and needs a tax rate needs to do the double lookup: cust-state-taxrate. What would be nicest is if TAX.RATE could be defined in CUSTOMER dictionary as a virtual field (perhaps a subroutine call for the multi-country case) so that rather than needing to do the double translate, you reference TRANS( CUSTOMER, CUST.ID, TAX.RATE, 'X' ) and you get back whatever data retrieval or calculation is defined ONCE in DICT CUSTOMER. In UV you cannot do this. Can you in UD? I suppose this is a sub-topic of the larger issue (virtue or tragic flaw; see flames in past threads) of the loose [non-]coupling of dictionary data access methods. cds --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Virtual fields calling Virtual fields
Hi All, Is it a bad thing when a virtual field references a virtual field in another file, which calles a sub-routine to retrieve values from yet another file? Does that even make sense? If not, how far could one take that before things do get bad? Thanks, John --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Virtual fields calling Virtual fields
John, Never tried to see how far it would go. The real issue is inefficiencyeach virtual field requires an additional read from the dictionary in which it is located. Doing this for every item in a report, you can see where the overhead makes chaining virtual fields inefficient. Drew Aherne, John wrote: Hi All, Is it a bad thing when a virtual field references a virtual field in another file, which calles a sub-routine to retrieve values from yet another file? Does that even make sense? If not, how far could one take that before things do get bad? Thanks, John --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- -- Drew Henderson 110 Ginger Hall Dir. for Computer Center OperationsMorehead State University [EMAIL PROTECTED] Morehead, kY 40351 (606) 783-2445 -- --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Virtual fields calling Virtual fields
Hey John, Actually, it makes perfect sense. In the old days, where you had 20 dumb terminals attached to a system that barely equaled the processing power of a 10 MHz PC-AT, you could really hammer the system by having embedded calls in dict items. The old days were the early 90's. 15 years later, the systems are so incredibly fast that you can get away with doing just about anything no matter how complex However, the methodology remains the same. Try it, and if it's not too slow to live with, then it's fine. If it's slower than molasses on a cold winter morning AND you're in a hurry, then it's time to try a different approach. If your willing to wait, then again, it's fine. I recently had a client that wanted a report that pulled from an enormous transactional based file. I offered to create an index to improve performance, but they declined saying that there were currently using Excel and manual data entry to create the same report at the end of the month, and that having it run in 15 minutes instead of 10 seconds was acceptable. So I just wrote it with a simple SELECT and it takes 15 minutes and they're happy as heck that it takes 15 minutes instead of the two days it used to take them to do it in Excel. Allen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Aherne, John Sent: Friday, February 18, 2005 11:37 To: u2-users@listserver.u2ug.org Subject: [U2] Virtual fields calling Virtual fields Hi All, Is it a bad thing when a virtual field references a virtual field in another file, which calles a sub-routine to retrieve values from yet another file? Does that even make sense? If not, how far could one take that before things do get bad? Thanks, John --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Virtual fields calling Virtual fields
inefficient compared to what? And Inefficient measured how? And is said Efficiency necessarily the significant software quality attribute when up against competing attributes such as Maintainability, Reusability, Robustness. Of course, there's no single right answer. I'm just being curmudgeonly. So, John, you often have to take things very very far before things get bad. Virtual fields are very very nice. (except for that EXTRACT() instead of varfld business mentioned earlier today. Now I'm being curmudgeonly again.) cds -Original Message- From: Drew Henderson John, Never tried to see how far it would go. The real issue is inefficiencyeach virtual field requires an additional read from the dictionary in which it is located. Doing this for every item in a report, you can see where the overhead makes chaining virtual fields inefficient. Drew Aherne, John wrote: Hi All, Is it a bad thing when a virtual field references a virtual field in another file, which calles a sub-routine to retrieve values from yet another file? Does that even make sense? If not, how far could one take that before things do get bad? Thanks, John --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Virtual fields calling Virtual fields
Yah, when I started programming, I used to count the clock cycles of instructions in C to see which method to use to do things :) I guess I have never gotten out of that mentality, which is why it offends my sensibilities to do things just because it is the easy way. I thought, though, that maybe that UD might do some magic in the way it handles things like nested calls to VF's. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Allen E. Elwood Sent: Friday, February 18, 2005 1:52 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Virtual fields calling Virtual fields Hey John, Actually, it makes perfect sense. In the old days, where you had 20 dumb terminals attached to a system that barely equaled the processing power of a 10 MHz PC-AT, you could really hammer the system by having embedded calls in dict items. The old days were the early 90's. 15 years later, the systems are so incredibly fast that you can get away with doing just about anything no matter how complex However, the methodology remains the same. Try it, and if it's not too slow to live with, then it's fine. If it's slower than molasses on a cold winter morning AND you're in a hurry, then it's time to try a different approach. If your willing to wait, then again, it's fine. I recently had a client that wanted a report that pulled from an enormous transactional based file. I offered to create an index to improve performance, but they declined saying that there were currently using Excel and manual data entry to create the same report at the end of the month, and that having it run in 15 minutes instead of 10 seconds was acceptable. So I just wrote it with a simple SELECT and it takes 15 minutes and they're happy as heck that it takes 15 minutes instead of the two days it used to take them to do it in Excel. Allen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Aherne, John Sent: Friday, February 18, 2005 11:37 To: u2-users@listserver.u2ug.org Subject: [U2] Virtual fields calling Virtual fields Hi All, Is it a bad thing when a virtual field references a virtual field in another file, which calles a sub-routine to retrieve values from yet another file? Does that even make sense? If not, how far could one take that before things do get bad? Thanks, John --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Virtual fields calling Virtual fields
I recently had a client that wanted a report that pulled from an enormous transactional based file. I offered to create an index to improve performance, but they declined saying that there were currently using Excel and manual data entry to create the same report at the end of the month, and that having it run in 15 minutes instead of 10 seconds was acceptable. So I just wrote it with a simple SELECT and it takes 15 minutes and they're happy as heck that it takes 15 minutes instead of the two days it used to take them to do it in Excel. We are in the midst of converting from D3 to UniData on AIX (RS/6000 M80). I just tested an inventory select that takes nearly two hours on D3. It finished in under 8 minutes on UniData. This involves selecting about 30,000 records from a file of nearly 800,000 VERY large records, about 60% of them over 2K, i.e. pointer items on D3. That's a pretty dramatic improvement. === Norman Morgan [EMAIL PROTECTED] http://www.brake.com === Boyd, Dewey, Cheatham and Howe -- Attorneys at Law === -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.8 - Release Date: 2/14/2005 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Virtual fields calling Virtual fields
The real issue is inefficiencyeach virtual field requires an additional read from the dictionary in which it is located. Doing this for every item in a report, you can see where the overhead makes chaining virtual fields inefficient. I think that the above conjecture is probably wrong. I think if you generated (compiled) a compound dictionary (C) made up of dictionary A and B. Then you deleted dictionary A B the compound dictionary, A, would still work (though would not recompile in the future). Thus, proving, there is no read at runtime of component dictionaries. Hence, it can be stated that there is no particular inefficiency caused by compounding dictionaries, other than the efficiency of the components themselves. In fact, there are some that would say that the construction of new , more complex, components from existing simpler components is something to be desired. Cheers, Stuart ** This email message and any files transmitted with it are confidential and intended solely for the use of addressed recipient(s). If you have received this email in error please notify the Spotless IS Support Centre (61 3 9269 7555) immediately who will advise further action. This footnote also confirms that this email message has been scanned for the presence of computer viruses. ** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Virtual fields calling Virtual fields
FWIW, Although in theory this technique may logically access multiple dictionary items for every record read, and potentially worse, if other records are accessed by some foreign key, in practice there is so much cache memory floating around in a commercial (and even home based) system, that the physical reads are only a fraction of what they used to be, in coal-powered systems. For a start, one I-type may use several other I-types in its execution but they are compiled into pseudo-subroutine so it is NOT the case that each element causes a Dict read. So in the case of say 3 Dict entries TOM, DICK and HARRY where TOM = A+B, DICK = C+D and HARRY = TOM + DICK , once they have been compiled TOM and DICK can be deleted but independent HARRY keeps on running (at least until it gets re-compiled). Even paged memory is unlikely to be rolled out to disk as this is only likely to happen if your discs [US translation: Disks] cannot deliver data fast enough to keep the cache alive. If however you use a foriegn key to access a record from secondary file from whence you need several fields (e.g. a read to a Product record for Description, weight, and colour [color]) then you could shave off a little time by pulling-in the whole record in one hit (@record) and slice and dice it within the I-type or subroutine. For a one-off this may not be worth the time to set up, but a weekly run on a big file is another story. Sadly, I'm getting a bit rusty on Uv these days as all our new stuff is SQL based - but keep flying the flag y'hear. Ray (the celt [kelt]) - G! --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
