none
Has MemoryFailPoint got more expensive in .Net 4.5 or is it x64 mode that's my problem? RRS feed

  • Question

  • I've got some code that I've recently noticed has got a lot slower. I finally profiled it and found that all the CPU time was being spent in the MemoryFailPoint constructor.

    I do create a lot of MemoryFailPoints whilst this code is running, as it's doing a lot of memory mapped file access, and our code for that is being defensive (as we used to have problems when running in 32-bit mode), but it used to run MUCH more quickly. Taking the MemoryFailPoint out makes things really fast again

    The only 2 major things I can think of that have changed since the code was written (and was fast) are:

    • We're now running only in 64 bit mode.
    • We've installed (but not built against) .Net 4.5

    Any ideas? Is it even worth using MemoryFailPoint when running in a 64bit process?

    Thursday, January 17, 2013 4:27 PM

Answers

  • Well, it turns out my initial assumption in the first line of my post was wrong. The code had, in fact, NOT recently got slower. It got slower more than a year ago when we first put the MemoryFailPoint in!

    So... MemoryFailPoint is slow enough that you don't want to use it inside a tight loop (which shouldn't really be a surprise), but it doesn't look like the performance has changed any time since the initial release of .Net 4.0.

    Monday, January 21, 2013 6:02 PM

All replies

  • Shortly, it doesn't worth to do it.

    It just check the resources.


    Ghost,
    Call me ghost for short, Thanks
    To get the better answer, it should be a better question.

    Friday, January 18, 2013 4:43 PM
  • Indeed it does, but it very much helped us avoid OutOfMemoryExceptions (which you really shouldn't try to catch) in non-critical paths in our code (e.g. image rendering) when other more critical paths are running on other threads (e.g. saving data). When we were running in 32bit mode we had a LOT of problems with running out of contiguous address space for mapping in large memory blocks (due to fragmentation of the LOH). We don't see this as much on x64, but we definitely do still see the MemoryFailPoint catching problems for us.

    What I am thinking is that MemoryFailPoint isn't worth it when doing MemoryMappedFile access (esp. on x64) as it might fail when we are out of virtual memory (i.e. the page file is full and allocation would fail) but there is plenty of address space left. As a MMF won't need any of the page file that isn't a problem. I'm already catching any IOExceptions and checking for ERROR_NOT_ENOUGH_MEMORY (as below) so hopefully that's enough.

    try
    {
        return this.mappedImageData.CreateViewAccessor(viewOffset, size);
    }
    catch (IOException ex)
    {
        if (Marshal.GetHRForException(ex) == unchecked((int)0x80070008)) // ERROR_NOT_ENOUGH_MEMORY
        {
            double sizeInMB = size / 1048576.0;
            string additionalMessage = string.Format(CultureInfo.InvariantCulture, "Insufficient memory to access image data. Requested size {0} MB", sizeInMB);
            throw new InsufficientMemoryException(additionalMessage, ex);
        }
    
        throw;
    }

    BTW: This definitely isn't a 64bit only slow-down. Running the same code in 32bit mode (on the same PC) is actually slower! I'm going to continue looking to see if I can find out when the performance changed.

    Monday, January 21, 2013 10:19 AM
  • Hi James,

    Good luck.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, January 21, 2013 11:02 AM
    Moderator
  • Well, it turns out my initial assumption in the first line of my post was wrong. The code had, in fact, NOT recently got slower. It got slower more than a year ago when we first put the MemoryFailPoint in!

    So... MemoryFailPoint is slow enough that you don't want to use it inside a tight loop (which shouldn't really be a surprise), but it doesn't look like the performance has changed any time since the initial release of .Net 4.0.

    Monday, January 21, 2013 6:02 PM