In an operating system, a Memory Mapping file are virtual storage place which has direct byte to byte correlation between the Virtual Address Space and the corresponding physical storage. So when we access the Virtual Address space via a memory mapping file we are directly communicating with the kernel space where the file is actually loaded. The portion of calculation between the physical storage and logical storage is hence avoided.
Memory Mapping files allows application to access files in the same way as memory. Generally as address between the physical storage and virtual memory address space, we cannot access the physical address directly. But using Memory Mapping Files, the process loads a specific range of address within the process address space with which the storage of memory into the file can be done by just assigning value to a dereferenced pointers. The IO operation on a MemoryMapping file is so fast that from the programmers point of view it seems to be like accessing the memory rather than actual physical storage. To increase performance memory mapping files are not actually stored to the disk file as well, but rather it will be stored automatically in background when FlushViewOfFile is executed or paging file is written. To Read more about memory mapping files, read here.
Memory Mapping file inside .NET Framework
.NET introduces a separate namespace to handle Memory Mapping files. Previously, we needed to do this using unmanaged Api's but with the introduction of managed API into the .NET framework library, it becomes very easy to handle MemoryMapping file directly from .NET library.
As memory mapping files are loaded into memory on a separate range of address space, two process can easily share the same page file instance and thus interprocess communication can be made with fast access to memory. It is recommended to back data with an actual disk file when large data is loaded into memory, so that there is no memory leak on the system when there is large memory pressure.
Handy Tricks and Tips to do your .NET code Fast, Efficient and Simple. Some common questions that comes into mind. Please check if you could find them listed or not.
Pages
▼
Monday, February 27, 2012
Saturday, February 4, 2012
Optimizing INPC Objects against memory leaks using WeakEvents
Working with WPF has always been a fun. Dealing with animation and richness in UI to its optimum level often gives you an edge to present something to your client and to ensure that your client shouts with a "WOW!". The Wow factor of applications can give you high rank in the first place, but increases expectation from the software. It is practically very hard to maintain with this expectation as time progresses. The survival of the fittest chooses one which best suits to the problem.
One of the major problems that developers face today is the memory leaks in an applications. Often the software that is built looks great but does not follow basic guidelines to ensure that the application is not memory hungry or even there are no existing memory leaks.
Note : By memory leak we mean, some portion of memory is not reclaimed by the garbage collector even though the object is not in use.
By this way, the memory usage of the application increases at a certain extent and finally crashes with the OutOfMemoryException. To detect a memory leak there exists a large number of tools of which some are free while others are used as commercial purposes. Most of these problems can be fixed by either using Disposable pattern ( IDisposable interface) or manually de - referencing each and every object that are not in use. Sometimes, this can be also done in destructor / finalizers in .net too (but remember using destructors lose GC cycle).
One of the major problems that developers face today is the memory leaks in an applications. Often the software that is built looks great but does not follow basic guidelines to ensure that the application is not memory hungry or even there are no existing memory leaks.
Note : By memory leak we mean, some portion of memory is not reclaimed by the garbage collector even though the object is not in use.
By this way, the memory usage of the application increases at a certain extent and finally crashes with the OutOfMemoryException. To detect a memory leak there exists a large number of tools of which some are free while others are used as commercial purposes. Most of these problems can be fixed by either using Disposable pattern ( IDisposable interface) or manually de - referencing each and every object that are not in use. Sometimes, this can be also done in destructor / finalizers in .net too (but remember using destructors lose GC cycle).