¿Cómo configurar MinWorkingSet y MaxWorkingSet en un proceso de .NET de 64 bits?

Question

¿Cómo configuro MinWorkingSet y MaxWorking para un proceso de .NET de 64 bits?

p.s. Puedo fijar el conjunto MinWorkingSet y MaxWorking para un proceso de 32 bits, de la siguiente manera:

[DllImport("KERNEL32.DLL", EntryPoint = "SetProcessWorkingSetSize", SetLastError = true, CallingConvention = CallingConvention.StdCall)] 
internal static extern bool SetProcessWorkingSetSize(IntPtr pProcess, int dwMinimumWorkingSetSize, int dwMaximumWorkingSetSize); 

[DllImport("KERNEL32.DLL", EntryPoint = "GetCurrentProcess", SetLastError = true, CallingConvention = CallingConvention.StdCall)] 
internal static extern IntPtr MyGetCurrentProcess(); 

// In main(): 
SetProcessWorkingSetSize(Process.GetCurrentProcess().Handle, int.MaxValue, int.MaxValue); 

Answer 1

Todo lo que tiene que hacer es cambiar su declaración de este modo:

[DllImport("KERNEL32.DLL", EntryPoint = "SetProcessWorkingSetSize", 
    SetLastError = true, CallingConvention = CallingConvention.StdCall)] 
internal static extern bool SetProcessWorkingSetSize(IntPtr pProcess, 
    long dwMinimumWorkingSetSize, long dwMaximumWorkingSetSize); 

La razón se debe a la definition of the SetProcessWorkingSetSize function:

BOOL WINAPI SetProcessWorkingSetSize(
    _In_ HANDLE hProcess, 
    _In_ SIZE_T dwMinimumWorkingSetSize, 
    _In_ SIZE_T dwMaximumWorkingSetSize 
); 

Tenga en cuenta que no utiliza un (entero como de 32 bits) DWORD sino un SIZE_T, que is defined as:

El número máximo de bytes a los que puede apuntar un puntero. Úselo para un recuento de que debe abarcar todo el rango de un puntero. Este tipo se declaró en BaseTsd.h como sigue:

typedef ULONG_PTR SIZE_T; 

Esto significa que es un valor de 64 bits, por lo tanto, la capacidad de cambiar a un long y tienen la función de trabajo en sistemas de 64 bits. También, desde la sección de MSDN titulado "Common Visual C++ 64-bit Migration Issues":

size_t, time_t, y ptrdiff_t son valores de 64 bits en sistemas operativos Windows de 64 bits.

Sin embargo, esto presenta un poco de un dilema, en el sentido de que no desea tener que compilar ensambles específicos de la plataforma (que sería un PITA). Usted puede evitar esto mediante el aprovechamiento de la EntryPoint field en el DllImportAttribute class (que ya se está haciendo) para tener dos declaraciones de métodos:

[DllImport("KERNEL32.DLL", EntryPoint = "SetProcessWorkingSetSize", 
    SetLastError = true, CallingConvention = CallingConvention.StdCall)] 
internal static extern bool SetProcessWorkingSetSize32(IntPtr pProcess, 
    int dwMinimumWorkingSetSize, int dwMaximumWorkingSetSize); 

[DllImport("KERNEL32.DLL", EntryPoint = "SetProcessWorkingSetSize", 
    SetLastError = true, CallingConvention = CallingConvention.StdCall)] 
internal static extern bool SetProcessWorkingSetSize64(IntPtr pProcess, 
    long dwMinimumWorkingSetSize, long dwMaximumWorkingSetSize); 

Ahora usted tiene dos firmas independientes. Sin embargo, saber que firma para llamar sigue siendo un problema. No desea colocar controles condicionales en todas partes. Con ese fin, recomendaría crear un método que realice el control por usted y lo llame.

Querrá utilizar el Is64BitProcess property en el Environment class para tomar esta determinación. No use el Is64BitOperatingSystem property. Desea lo primero porque los procesos de 32 bits se pueden ejecutar en sistemas operativos de 64 bits, y desea asegurarse de que su código sea resistente a eso; solo verificando si el sistema que opera es de 64 bits no le da la imagen completa.

Answer 2

No pinvoke esto, solo use la propiedad Process.CurrentProcess.MinWorkingSet directamente.

Probabilidades muy altas de que esto no hará ninguna diferencia. Las fallas de búsqueda suave son completamente normales y se resuelven muy rápido si la máquina tiene suficiente RAM. Toma ~ 0.7 microsegundos en mi computadora portátil.No puede evitarlos, es el comportamiento de un sistema operativo de memoria virtual demand_paged como Windows. Muy barato, siempre y cuando haya a free page readily available.

Pero si "blips" programa el rendimiento, entonces debe considerar la posibilidad de que no esté disponible y desencadene un error de página difícil en otro proceso. La falla de paginación se vuelve costosa si la página de RAM debe ser robada de otro proceso, su contenido debe ser almacenado en el archivo de paginación y debe ser reiniciado nuevamente a cero. Eso puede sumarse rápidamente, cientos de microsegundos no es inusual.

La ley básica de "no hay almuerzo gratis", necesita ejecutar menos procesos o comprar más RAM. Con la última opción, la opción correcta, 8 gigabytes te devuelve aproximadamente 75 dólares hoy. Robo completo.