tags:

views:

86

answers:

1

Hi,

Can anyone give me a simple example of how to use SafebUffer. i.e how do I create and initialise one - MSDN docs don't appear to show this.

+1  A: 

You can't, it is an abstract class. The only visible concrete implementation of it is SafeMemoryMappedViewHandle, a helper class for the classes in the System.IO.MemoryMappedFiles namespace. It has a non-accessible constructor since it can only be properly initialized by the plumbing that makes memory mapped files work.

The use case is an IntPtr that maps to unmanaged memory, managed by a handle. Fairly rare in the Windows API, MapViewOfFile or GlobalAllocPtr for example. If you want to create your own then you have to derive from SafeBuffer so you can call its constructor and call, say, AcquirePointer. Most of this is unsafe. What are you really trying to do?

Hans Passant
I am trying to read a very large file (bytestream) from disk into an UnmanagedMemoryStream. The file is greater than the maximum number of bytes a bytearray can hold.
ManInMoon
Well, use the .NET 4.0 support for memory mapped files. Pointless to reinvent MemoryMappedViewStream. It doesn't actually make reading the file any quicker.
Hans Passant
Thanks Hans. I have tried that but MemoryMappedFiles are very slow
ManInMoon
No, reading a file from the disk is slow. A MMF is as fast as you can ever get but the initial data still needs to come off that slow spinning disk. The only way you can make that faster is to use a faster disk. SSDs are nice. Using multiple threads is a mistake too, CPU cycles is not your resource constraint. They'll just take turns waiting for the disk driver. Testing this gives you the wrong impression, running your test the 2nd time gives you data from the file system cache, not the disk. That won't happen in production.
Hans Passant
ACtually, I thought that too. But I tested it on second run - and it appears to take same speed...What I don't understand is why when I load 3G file with a fileread it loads in maybe 5 seconds - but MMF version, possibly due to paging takes minutes. Then on second run - takes minutes as well. Perhaps I have it set-up wrong
ManInMoon
You'll lose when the file is too large for the file system cache. It will start dropping file data that hasn't been used for a while. The data from the beginning of the file. Don't focus on that, in production the data won't be in the cache either.
Hans Passant
What do you mean by production? I am constantly re-building the app as I develop it - there is no production version - it is a research vehicle that's constantly changing
ManInMoon
Production == using the app in the environment it will actually be used. As opposed to your dev machine where you do things like running it frequently on the same data. Very unrealistic, gets you to focus on optimizing the wrong thing.
Hans Passant
Ah I see. The difference is - there is no production! I am not a developer, this code is for my own number-crunching - so it is run pretty much like I have outlined here...
ManInMoon