OpenFileRequester() Huge Memory Usage

[TI-994A]

Hello everyone. Quick question: is there any reason why the OpenFileRequester() takes up so much runtime memory? A program's memory usage would jump as much as 25MB when the requester is called, and does not shrink again, unless the program window is minimized. Following that, subsequent calls to the requester would take up about half the initial size, jumping about 12MB when called.

Is that normal?

[dige]

It's just a guess, OpenFileRequester() is only a wrapper for an api call.
If you look more closely at the window, it has a lot of functionality - almost like an explorer.

[deeproot]

On a very quick test - it doesn't do that for me.

Observed using only Task Manager:-

Calling OpenFileRequester the first time, memory use jumps up by about 5Mb. Then stays there after it is closed. Calling OpenFileRequester a 2nd or 3rd time does not change the memory use at all.

Minimizing the window drops memory usage really low, restoring it increases it only to a fairly low level - then gradually grows back as various program functions are used (presumably being pulled back from paged memory as needed). But OpenFileRequester does not appear to have much bearing on this - behaves much the same whether it's been opened or not.

Running on Windows XP Sp3, PB 5.00 x86 - compiled exe (not from IDE with debug etc). Normally program use is roughly between 30 - 40Mb, occasionally a little more when certain program features are used - pretty modest given what it's doing!

[Fred]

May be you have a program which hooks Explorer ?

[TI-994A]

Thank you everyone for all your replies.

It's just a guess, OpenFileRequester() is only a wrapper for an api call.

Hi dige. Yes, and I did try calling the GetOpenFileName() API from PureBasic, and the results are the same.

Calling OpenFileRequester the first time, memory use jumps up by about 5Mb. Then stays there after it is closed. Calling OpenFileRequester a 2nd or 3rd time does not change the memory use at all.

Minimizing the window drops memory usage really low, restoring it increases it only to a fairly low level - then gradually grows back as various program functions are used (presumably being pulled back from paged memory as needed).

Precisely, although the initial jump in memory usage was a lot higher for me; 25MB (compiled exe with PureBasic 5.0 on WinXP Home SP3).

May be you have a program which hooks Explorer ?

Hi Fred. It's occurring even in the most basic applications. In fact, I noticed this in the example that was created in my Form Designer tutorial video. And I get the same results with C++ as well (CodeBlocks + MingW).

Is there any way to release the memory use after closing the dialog, besides minimizing the program window?

[luis]

Hi TI

A program's memory usage would jump as much as 25MB when the requester is called, and does not shrink again, unless the program window is minimized

From this description I would say it's a normal behavior ... anyway I think Fred wanted to know if you have a third party software which is hooking explorer (not in your code I mean).

Is there any way to release the memory use after closing the dialog, besides minimizing the program window?

If you want to see the memory usage drop for your personal satisfaction (without any real advantage because the OS can do the same if and when it's really needed) you can try the EmpyWorkingSet API, it should work I think.

Just call it when you want to squeeze the memory usage.

Code: Select all

Procedure.i EmptyWorkingSet (hProcess)
; [DESC]
; Removes as many pages as possible from the working set of the specified process.
;
; [INPUT]
; hProcess : Handle of process (for example GetCurrentProcess_())
; 	
; [RETURN]
; 1 if successful, else 0.

 Protected *EmptyWorkingSet
 Protected hDll, iRetVal
 
 ; Windows XP and later, Windows 2000 Professional, or Windows NT Workstation 4.0
 If (OSVersion() >= #PB_OS_Windows_2000 Or OSVersion() = #PB_OS_Windows_NT_4)
     hDll = OpenLibrary(#PB_Any, "Psapi.dll")    
     
     If hDll 
        *EmptyWorkingSet = GetFunction(hDll, "EmptyWorkingSet")
        
        If *EmptyWorkingSet
            If CallFunctionFast(*EmptyWorkingSet, hProcess) <> 0
                iRetVal = 1
            EndIf
        EndIf    
        CloseLibrary(hDll)
     EndIf
 EndIf
 ProcedureReturn iRetVal 
EndProcedure

[TI-994A]

If you want to see the memory usage drop for your personal satisfaction (without any real advantage because the OS can do the same if and when it's really needed) you can try the EmpyWorkingSet API, it should work I think.

Hi luis. You're right about OS memory management, but with security software nowadays monitoring memory usage, I'd prefer that a high-memory-usage warning did not pop-up against my apps. EmptyWorkingSet() seems to do the trick; I'll study it a little more. Thank you for that.

[MachineCode]

is there any reason why the OpenFileRequester() takes up so much runtime memory?

I have no idea as it never does it to me, but my guess is maybe if OpenFileRequester() is using thumbnail views as the default, and thus loading tonnes of thumbnails for display?