I know what you're saying, but just to make sure we're precise I'll add a footnote. The run-time machine doesn't have to find additional memory *each* time you add to a dynamic array (as you said perhaps just imprecisely). Rather, your workspace arrays have certain fixed sizes and it's only when you go over this size that it will allocate you a new larger area and move the array there. So for example, you get slots that are 50 bytes, 250 bytes, and so on, probably implementation dependent. The run-time machine will allocate you a smaller area at first, until it knows you need a bigger one.
Alternatively, garbage collection will return to the available pool, the no longer used space for arrays that have shrunk. I never did any testing to see if the garbage collector actually works *while* your program is running or only after the signal that the program is now finished. I do agree however with the observation that reading a large amount of data into a dynamic array is *most likely* causing the run-time machine to allocate you the entire size of that data in your own *workspace*. Danger Will Robinson! Warning! Warning! When it runs out of memory/disk will it wait forever? Or will it halt the system? "Try again later, answer fuzzy". Will Johnson -----Original Message----- From: John Hester <[email protected]> To: U2 Users List <[email protected]> Sent: Tue, May 18, 2010 12:31 pm Subject: Re: [U2] OPENSEQ and Abnormal termination of UV Reading my own response just made me realize what's going on. I think Jerry's response was right. I remember many years ago (I won't say how many) when we were on much slower hardware, explaining to a coworker that it was better to use dimensioned arrays when possible because they were faster to populate than dynamic arrays. The reason they're faster is because the necessary space for them is already reserved in memory. A dynamic array has to go out and find add'l memory each time you add to it. Looks like putting a sequential file in a dimensioned array makes it go out and reserve a block of memory the size of the entire file. If that's the case then making FILEVARS a dynamic array *should* work. -John -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of John Hester Sent: Tuesday, May 18, 2010 11:42 AM To: U2 Users List Subject: Re: [U2] OPENSEQ and Abnormal termination of UV Yes, I see your point. I wonder if the integer gets treated like a string in the first instance. I wonder what the result with FILEVARS<1> would be. -John -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Anthony W. Youngman Sent: Tuesday, May 18, 2010 7:45 AM To: [email protected] Subject: Re: [U2] OPENSEQ and Abnormal termination of UV In message <[email protected]>, John Hester <[email protected]> writes >I think it's something along those lines, but I don't think it's trying >to stick the entire contents of the file into a variable. What I think >OPENSEQ is doing is keeping track of the position where the EOF mark is >so it will know when the end of the file is reached. For a file greater >than 2GB in size, this position is an integer that takes more than 32 >bits to store. UV, being a 32-bit application, is not going to be able >to handle it. The maximum positive integer value a 32-bit application >can reference is 2147483647. > The problem is, FV.FILE and FILEVARS(1) are *allegedly* *functionally* *identical*. An element of a dimensioned array, is supposed to be a normal variable in every way shape or form. The problem is that, in this instance, it clearly isn't because the variable works while the element (allegedly identical) causes a crash. I'd agree with Perry. It's a bug. _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
