This is a little catch-22. Years ago, there was a limit on the number of 'variables' a program had. This, since each element in a DIM array is a variable, you could not DIM REC(100000). Thus legacy code may have been forced to use dynamic arrays on large items.
Nowadays, we may not be held to any limits (or they are very large). Us programmers tend to stretch the limits of what's available at the time. Thus, knowing all of the programming options (array types, REMOVE, LOCATE, concatenation, work files etc), we can apply the best fit for the issue at hand. Mark Johnson ----- Original Message ----- From: "Baakkonen, Rodney A (Rod) 46K" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, July 23, 2008 3:48 PM Subject: RE: [U2] Basic SORT() Function not avail in UniVerse? > I guess my point was a little off topic, as I was really calling > attention to performance issues with dynamic arrays in general and not > about sorting keys. When dynamic arrays can out perform work files, we > will use them. > > We have seen processes that used dynamic arrays run for a week. Even > with doing REMOVE and using concatenation to build the array. Changing > the logic to use a work file resulted in the same process finishing in > hours. > > The other aspect is that a lot dynamic arrays in programs do more that > just hold keys. Doing a locate on one array may result in multiple data > elements being inserted into corresponding arrays. With this type of > intermediate data, writing and sorting a work file will run circles > around internal arrays. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rex Gozar > Sent: Wednesday, July 23, 2008 1:50 PM > To: [email protected] > Subject: Re: [U2] Basic SORT() Function not avail in UniVerse? > > I've done research on sorting in the past, working with 100,000 to > 1,000,000 element lists. > > Allen: LOCATE's are faster, but only when you're dealing with less than > 100 elements. Because LOCATE's must start at the beginning of a string > and traverse the entire length, they get slower and slower. Bubble > sorts are also useless when dealing with a large number of elements. > > Jeff: Yes, a C program is the fastest (at least it was at my last job > where we used GCI to integrate it with the universe shell.) > > As for writing out ids to work files just to sort them, it adds > unnecessary overhead to the whole process. > > I wish universe had an intrinsic sort() function. Since they don't I > wrote my own and posted it on PickWiki. You could also use the > QuickSort sample posted in this thread. Once you standardize on a > particular sorting program, you'll be amazed at the number of times it > comes in handy. > > http://www.pickwiki.com/cgi-bin/wiki.pl?Sorting > http://www.pickwiki.com/cgi-bin/wiki.pl?ShellSort > http://www.pickwiki.com/cgi-bin/wiki.pl?QuickSort > > Another handy function is to be able to flip fields to values and vice > versa. See http://www.pickwiki.com/cgi-bin/wiki.pl?Row2Col and again > it's optimized for a large number of elements. > > rex > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
