BinaryAlloc vs Available

[KeithW]

Tony,

Probably more your ballpark....   I did a BinAlloc for a 3,580M row (996,661KB file) and successfully got the allocation on my system.
Is there a way to find out how much room before I do that  AND  what is left after the buffer is built?

Regards,
Keith

[td]

What do you mean by room?  Are you referring to room in the buffer or are you referring to the memory available to the process?

[KeithW]

How much available memory... how big an allocation can you do before Allocating the Buffer
and if you wanted to do a second AFTER getting the first, how much available memory exists?

Keith

[td]

Binary buffer maximum size is limited to 1 GB with 64-bit WinBatch and a bit less on 32-bit WinBatch.  You have a little bit less than 1GB total memory for all binary buffers with 32-bit WinBatch.  The amount of process memory available to the WinBatch process and, therefore, binary buffers on 64-bit systems is completely dependent on the system.  Windows will not allocate more memory to any given process than the total system virtual memory.  To get a rough idea of how much that is check the size of the system page file.  Of course, WinBatch needs some memory for its internal use so you can subtract about 250 MB to 350 MB depending on the bitness.   The traditional way to determine how much memory is available is to allocate memory until you get an error.  Another approach would be to use dotNet, WMI, or DllCalls to Win32 process functions to obtain information about the amount of memory the process is using. The obtained number could then be compared to the system virtual memory or the 1 GB process limit depending on the bitness of the process.

There might be an example in the Tech Database or I might have something on my workstation.  I will need to check.

[td]

It would appear that I need to be assigned to the pontificator's penalty box again. The previous post has several errors because I failed to take Windows 10's memory compression feature into account.  This feature is enabled on most Windows 10 systems and changes the landscape of process memory considerably. 

I hacked together a quick and dirty script from snippets of other scripts on my system.  If you run it on a system with memory compression, it may do a better job showing the effects of memory compression than any half baked explanation I can offer.

Code (winbatch) Select Expand

;; Only interested in 64-bit results.
Terminate(WinMetrics(-2)!= 3, 'Bitness Check', 'Run using 64-bit WinBatch only')

;;; Max out memory
IntControl(73, 1,0,0,0)
for i = 0 to 128
   hbin%i% = BinaryAlloc(2147483647)
   continue
:WBERRORHANDLER
   break;
next
   
Pause("Out of Memory", "Check Task Manager's Performance Tab Committed numbers.")

for j = i - 1 to 0
   BinaryFree(hBin%j%)
next

Pause("Memory Freed", "Check Task Manager's Performance Tab Committed numbers.")

;;; Get this process's memory usage as reported by the CLR.
ObjectClrOption('useany', 'System')
objProcess = ObjectClrNew("System.Diagnostics.Process")
objThis = objProcess.GetCurrentProcess()

nMemUsed = ObjectType('R8',objThis.WorkingSet64  )    ; The amount of physical memory, in bytes, allocated for the associated process.
objThis = 0
objProcess = 0

;;; Get the max amount of memory the system will give to a process.
objOS = GetObject("WINMGMTS:\\.\ROOT\cimv2:Win32_OperatingSystem=@")
nSysVirtMem = ObjectType('R8', objOS.MaxProcessMemorySize)/1024.0
objOS = 0

Message('Memory Usage and System Total', 'Memory used by this process: ':Int(nMemUsed/(1024.0**2)):' MB':@lf:'OS max process memory ':Int(nSysVirtMem/(1024.0 **2)):' GB')

exit

[KeithW]

Tony,

Thanx for the script & follow-thru, I will look at in a bit...

Regards,
Keith