2

I have a Delphi 6 application and also a DLL that share a memory mapped file to transfer data between them. I know soft page faults are a normal side effect of memory mapped files, but I am getting a lot more than I think should (high PF Delta values in the Task Manager of about 2000 per second). Therefore I am posting the parts of my code that create the memory mapped file, write to it, and read from it to see if anyone can see some flaw in my approach. Here are the code excerpts below. Note, I am using a desired file size of 1MB:

// Uses pagefile.sys
procedure initFile(
                theFilename: string;
                theDesiredFilesize: integer;
                out theViewHandle: THandle;
                out theBaseAddressPtr: Pointer);
var
    MaximumSizeLow, MaximumSizeHigh: Cardinal;
begin
    I64ToCardinals(theDesiredFilesize, MaximumSizeLow, MaximumSizeHigh);

    theViewHandle :=

        CreateFileMapping(
                    INVALID_HANDLE_VALUE,
                    nil,
                    PAGE_READWRITE or SEC_COMMIT,
                    MaximumSizeHigh,
                    MaximumSizeLow,
                    PChar(theFilename));

    if theViewHandle = 0 then
        RaiseLastOSError;

    theBaseAddressPtr := MapViewOfFile (theViewHandle, FILE_MAP_ALL_ACCESS, 0, 0, 0);
end;

procedure TShareMem.doSaveBuffer(const theSourceBufPtr: Pointer; numBytes: integer);
var
    newSize: Int64;
begin
    if not Assigned(theSourceBufPtr) then
        raise Exception.Create('(doSaveBuffer) The source buffer pointer is unassigned.');

    newSize := numBytes;

    Move(theSourceBufPtr^, FDataBufferPtr^, newSize);

    // Increment the write count.
    Inc(FDataBufferHeader.writeCount);

    // Update the variable that lets others know the actual size of the
    //  object/data we just stored.
    FDataBufferHeader.sizeInUse := numBytes;

    // Update the header file.
    updateHeaderFile;
end;

procedure TShareMem.loadStream(theDestStream: TMemoryStream);
var
    theSize: Int64;
begin
    if not Assigned(theDestStream) then
        raise Exception.Create('(loadStream) The destination stream is unassigned.');

    updateHeader;

    // Rewind the destination stream.
    theDestStream.Position := 0;

    theSize := FDataBufferHeader.sizeInUse;
    theDestStream.Size := theSize;

    // Read data from the memory mapped data buffer into the stream.
    // theDestStream.WriteBuffer(FDataBufferPtr^, FDataBufferHeader.size);
    Move(FDataBufferPtr^, theDestStream.Memory^, theSize);
end;
menjaraz
  • 7,551
  • 4
  • 41
  • 81
Robert Oschler
  • 14,153
  • 18
  • 94
  • 227
  • How is the DLL hosted? What is the other process? – David Heffernan Jan 06 '12 at 16:24
  • @DavidHeffernan - The DLL is a DirectShow push source video filter, running in Graph Edit during testing. The other process is a standard EXE that receives JPEG frames and shares them with the DLL by writing them to the shared memory area, but only one JPEG frame buffer is in the shared memory area at a time (last one written). – Robert Oschler Jan 06 '12 at 16:33
  • Is it even possible to definitely say what your user-mode code will cause, inside the kernel, where Windows Virtual Memory management does its job? – Warren P Jan 06 '12 at 18:19
  • @ArnaudBouchez - The file name is jpeg_databuffer_dat. I'm using your jpegdecode library (wonderful tool) to decode the JPEG frames and I am having a strange problem with bitmap modifications not being visible in the rendered image. I don't think it's jpegdecode, but if you could take a look at the following post I'd appreciate it: http://stackoverflow.com/questions/8754620/changes-to-tbitmap-do-not-appear-in-rendered-image-in-delphi-6-directshow-filter – Robert Oschler Jan 06 '12 at 18:45
  • @WarrenP. I'm not sure what you are getting at Warren, sorry. – Robert Oschler Jan 06 '12 at 18:46
  • You're asking about the implementation of methods that you are invoking, and their costs in the terms used inside the Windows Kernel alone. There is no way to objectively answer your question, without superhuman, or at least Microsoft-source-code-for-windows-kernel capabilities. Your code does something trivial and obvious, and how it could be "rewritten to do fewer kernel soft page faults" seems unanswerable. – Warren P Jan 06 '12 at 20:45

0 Answers0