Получение 'из памяти' исключение в этой относительно простой программе

Вы должны освободить ресурсы, используемые при открытии объекта Image .

Вы можете вызвать Dispose или создать свой образ с помощью оператора Используя

например.

public override void getThumbnail(string filePath)
{
    using (Image image = Image.FromFile(filePath))
    {
        Thumbnail = image.GetThumbnailImage(40, 40, null, new IntPtr());
    }
}

А поскольку ваш класс содержит Image , вам следует реализовать интерфейс IDisposable , поэтому вы также можете использовать его в операторе using .

Несколько проблем провожу сразу. Во-первых, вы загружаете каждое изображение дважды с последующими вызовами CalculatePictureWidth и CalculatePictureHeight. Во-вторых, похоже, что вы на самом деле ничего не делаете с миниатюрой. В-третьих, вы должны вызвать Dispose для экземпляров Image, как только вы закончите сбор информации от них.

Файл образа содержит дескриптор большого блока неуправляемых данных. Эти данные необходимо удалить, и вы делаете это, явно вызывая Image.Dispose. Поскольку вы не вызываете Dispose в методах calculatePictureHeight и calculatePictureWidth, файлы изображений хранятся в памяти, что вызывает исключения OOM.

[Обновление]: Возможно, мне будет полезно немного больше информации, почему это происходит на самом деле. В конце концов, разве не существует GC, который убирает за нас этот беспорядок? Да, есть, и GC довольно эффективен. В конечном итоге он также очистит объекты, которые нам пришлось утилизировать.

Класс Image содержит финализатор. Этот финализатор гарантирует, что все ресурсы будут очищены, даже если вы забудете вызвать Dispose. Однако здесь происходит то, что у вас заканчивается память, что немедленно запускает GC.Collect. Во время этого сбора сборщик мусора находит все ваши изображения, на которые нет ссылок. Однако, поскольку сборщик мусора не запускает метод финализатора немедленно, все ваши объекты повышаются до Gen1 (они хранятся в памяти), как и все ваши ресурсы (собственная память). Таким образом, даже после того, как сборщик мусора сработал, памяти все еще недостаточно, и вы получите исключение OOM.

Вот почему вы всегда должны удалять объекты, реализующие IDisposable.

Вы не должны хранить все изображения в одном списке, вы должны делать то, что у вас есть, с одним изображением за раз и удалять каждое изображение после каждой итерации.

Проверьте метод Image.Dispose ().

Сколько изображений у вас в этой папке. Я вижу, как вы просматриваете все изображения в цикле, загружаете их напрямую в память и сохраняете их в виде списка. Это может быть причиной.

Я сильно подозреваю, что то, что вы видите, является странностью предсказания ветвей, а не чем-то связанным с кэшированием. В частности, на множестве ЦП прогнозирование ветвей не работает (а также | вообще), когда и источник, и цель ветви находятся в одной строке кэша. Размещение достаточного количества кода внутри цикла (даже НОП), чтобы получить источник и цель в различные строки кэша, даст существенное улучшение скорости.

ToShortDateString () не поддерживается Linq to SQL http ://msdn.microsoft.com/en-us/library/bb882657.aspx

Попробуйте взглянуть на свои образы: Я нашел определенную причину .jpg это - изображение манипулирующие библиотеки имеют проблемы с определенными изображениями, не уверен, почему. Но у нас есть определенные .jpg спасены от фотошопа какой-то странный способ вызвать это. Спорим, ты найдешь одно плохое яблоко.

Насколько велики ваши файлы изображений? Сколько файлов в вашем каталоге? В зависимости от этих параметров я мог увидеть, как вы можете получить OutOfMemory. Вы можете перепроверить свой подход. Вместо того, чтобы загружать все в память, вы должны загружать каждое изображение по отдельности, выполнять свое действие и затем продолжать (конечно, после того, как вы удалили предыдущее изображение).

Сможете ли вы это сделать?

public class Picture:BaseFile
{
    public int Height { get; set; }
    public int Width { get; set; }
    public Image Thumbnail { get; set; }

    /// <summary>
    /// Sets file information of an image from a given image in the file path.
    /// </summary>
    /// <param name="filePath">File path of the image.</param>
    public override void  getFileInformation(string filePath)
    {
        FileInfo fileInformation = new FileInfo(filePath);
        if (fileInformation.Exists)
        {
            /*
            Name, FileType, Size, etc
            */
            using (Image image = Image.FromFile(filePath))
            {
                Height = image.Height;
                Width = image.Width;
                Thumbnail = image.GetThumbnailImage(40, 40, new Image.GetThumbnailImageAbort(ThumbnailCallback), default(IntPtr));
            }
        }
    }

    public bool ThumbnailCallback()
    {
        return false;
    }
}

Несколько человек упомянули вызов утилиты после завершения работы с изображениями. Однако этого недостаточно, и .NET framework сделает за вас то, что используется при увеличении использования памяти. Поскольку вы добавили каждое изображение в связанный список, платформа .NET не может от него избавиться, поскольку вы неявно сохраняете ссылку.

Это означает, что все данные, хранящиеся в классе изображений, сохраняются во время цикла foreach. Из фрагмента кода я не могу понять, что это такое, он может включать сжатую или даже несжатую версию изображений, которые могут объяснить ваш взрыв памяти.

[Edit] удалила часть ответа, которая, по мнению других, неуместна; Я предположил, что класс изображения - это класс изображения XNA.