Yes I have compared the performance. Within the ERP system I worked in we saw little difference. Yes dimensioned arrays MAY have some advantage under certain circumstances, but reading and accessing fields in a record is not one of them. Certainly not enough to justify throwing away one of the best features of the Pick database, or having to code work-arounds to deal with the short-comings of dimensioned arrays.
Again I am referring to the use of MATREADS and WRITES primarily here. When you do this the dim'd array only provides any benefits when accessing fields. When you get to dealing with value and sub-value mark separated data you are back to the 'slower' text extraction. I generally don't like using dimensioned arrays at all, but outside of handling actual record structures they do have their uses. Rich Taylor | Senior Programmer/Analyst| VERTIS 250 W. Pratt Street | Baltimore, MD 21201 P 410.361.8688 | F 410.528.0319 [EMAIL PROTECTED] | http://www.vertisinc.com Vertis is the premier provider of targeted advertising, media, and marketing services that drive consumers to marketers more effectively. "The more they complicate the plumbing the easier it is to stop up the drain" - Montgomery Scott NCC-1701 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, May 13, 2005 2:54 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] I'm in an Array quandry, any suggestions... Richard Taylor <[EMAIL PROTECTED]> wrote on 05/13/2005 02:05:51 PM: > ... Why take a flexible, dynamic database system and force it to > be fixed length. This is what you are doing using dimensioned arrays and > MATREADs. The most common justification I have heard is performance and > this simply doe not hold water. Have you ever compared performance between dynamic and dimensioned arrays, or are you just saying that you've never notice problems but have never tried dimensioned arrays? I've seen it make a HUGE difference in Pick, UniVerse, and UniData. If you reference many elements of a dynamic array many times, you'll burn a lot of CPU cycles just to locate the data. When you reference an element of a dimensioned array, it's stored in separate address space, and is immediately referenced. I have a standard way to avoid problems with the last attribute folding into the highest array element. Just dimension the array one element larger than the highest attribute you reference in the program. So if the highest attribute you reference is number 72, dimension the array at 73 or higher. Where I used to work, we had an automated process that created file definitions, including standard equates and the code to dimension arrays. We always created the arrays at one more than the highest attribute, and never had problems. This won't be necessary in environments where the extra attributes are placed on element zero, but it won't hurt anything, either. That way your code will be portable. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] ------- 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/
