1. Re: SET CAUSEWAY VARIABLE
- Posted by Robert Craig <72614.1667 at COMPUSERVE.COM>
Jun 28, 1996
-
Last edited Jun 29, 1996
On June 28, Marcel Kollenaar wrote:
> On your advice I put the SET CAUSEWAY=SWAP:C:\APPL\TEMP environment
> var in the AUTOEXEC.BAT file and gave smartdrive only 1024 Bytes
> under Windows and 0 under DOS with "C:\WINDOWS\SMARTDRV.EXE 0 1024".
> Started the system again but I get the same "Your progr.." message.
"SET CAUSEWAY=SWAP:..." will have no effect under Windows. It only
matters when you are running outside Windows on pure DOS.
Under Windows you will get virtual memory from the Windows
system swap file. Under Windows 95, I'm not sure if SMARTDRV has
any effect either.
> It still happens in the get.e module. What I don't understand is
> that the program can initialise and fill a list of 100,000 integer
> items in the form of {{n,n},{n,n},..}. The program can sort it with
> the sort.e program, I can write it to disk to a file, 1,400,000
> bytes. But I can't read it from disk in the same list.
Euphoria stores integer values in 4 bytes. Each sequence has an
overhead of about 20 to 24 bytes for control information (22 average). So
a 2-element sequence of integers would actually consume 22 + 2*4 = 30
bytes. So 100,000 pairs would need 100000*30 = 3,000,000 bytes.
For a long sequence (of length > 20 say) the overhead isn't of much
concern, but for 2-element sequences the overhead exceeds the cost of
storing the elements themselves.
The Windows 95 operating system consumes more (virtual) memory than
Win 3.1. The memory available to you would be the total RAM + a few
megs of swap space minus the space consumed by the operating system,
disk cache, and swapped out applications. You can get more
memory under pure DOS. On a 24 Mb RAM Windows 95 system ed was able
to get about 20 Mb or so before getting "out of memory".
Under pure DOS the swap file will keep growing automatically if you
still have free disk space. Under Windows the operating system limits
the growth to some number. You can increase the swap space but
eventually your application is likely to run very slowly.
> Between the
> write and read step I make the list empty with the statement
> LIST = {}
This is a valid thing to do. However if you have any other
variables that are still "pointing" to the same data, it
won't be freed. Sometimes you can even have a temporary
intermediate expression result that you recently calculated
still in memory that won't be freed right away. So you might
temporarily be using more memory that it appears.
Another issue is that when get() reads in your data it uses
append() to build up the resulting sequence. append() sometimes
has to make a whole new copy of a sequence, when there is
no more room to grow. So for a moment 2 copies are in memory.
Finally, make sure your numbers are integers - no fractional
part and within +/- 1,000,000,000 roughly. Floating point
numbers consume about 20 bytes each.
I typed in this quick example of what you seem to be doing and it
ran ok for me under windows 3.1 with an 8Mb RAM machine.
It generated a 1.5 Mb "junk.dat" file.
I will try it later on a win95 machine. Maybe you can post some of
your code so we can see more precisely what you are doing.
----------- start of example -----------------------
include get.e
sequence s
integer fn
s = rand(repeat({1000000,1000000}, 100000))
fn = open("junk.dat", "w")
print(fn, s)
close(fn)
s = {}
fn = open("junk.dat", "r")
s = get(fn)
if s[1] = GET_SUCCESS then
s = s[2]
end if
?length(s)
-- should print 100000
------------- end of example --------------------
Regards,
Rob Craig
Rapid Deployment Software
