На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
Обратите внимание:
1. Прежде чем начать новую тему или отправить сообщение, убедитесь, что вы не нарушаете правил форума!
2. Обязательно воспользуйтесь поиском. Возможно, Ваш вопрос уже обсуждали. Полезные ссылки приведены ниже.
3. Темы с просьбой выполнить какую-либо работу за автора в этом разделе не обсуждаются.
4. Используйте теги [ code=cpp ] ...текст программы... [ /code ] для выделения текста программы подсветкой.
5. Помните, здесь телепатов нет. Старайтесь формулировать свой вопрос максимально грамотно и чётко: Как правильно задавать вопросы
6. Запрещено отвечать в темы месячной и более давности без веских на то причин.

Полезные ссылки:
user posted image FAQ Сайта (C++) user posted image FAQ Форума user posted image Наши Исходники user posted image Поиск по Разделу user posted image MSDN Library Online (Windows Driver Kit) user posted image Google

Ваше мнение о модераторах: user posted image B.V.
Модераторы: B.V.
  
> Скорость FlushViewOfFile
    Я пишу на диск данные. Для этого юзаю mapping files. Очень критична скорость записи.

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

    Например, надо скинуть 40 Мб. Быстрее будет 1000 раз по 40 кб, чем 1 раз 40 Мб. Почему? И не быстрее ли будет использовать WriteFile?
      WriteFile будет по скорости работать столько же ( при равных условиях ), разница в единицы процентов. А вот с размерами блоков все довольно запутано. На разных системах у меня получалось что либо скорость чтения/записи имеет выраженный максимум в районе 64К, либо после 64К скорость записи/чтения не зависит от размера блоков. На самом деле драйвер диска инициализирует DMA операции при доступе к диску. При чем за одну операцию вроде не более 64К. Таким образом, почему при размере буфера 64К произовдительность перестает расти более менее понятно. Но почему она на некоторых системах начинает падать - для меня загадка, возможно все дело в конкретных реализациях драйверов. Ожидаемым поведением было бы следующее: быстрый рост производительности при увелечении размера буфера от 1 байта до ~4К, далее постепенное замедление и после 64К очень незначительный рост производительности.
        Я в этом случае просто при установке параметров программы - задании папки, куда складываются данные - просто тратил несколько секунд на поиск оптимального значения размера блока. Теоретически, это не так уж часто придется делать и пользователь может потерпеть - для его же пользы :). И TarasCo прав, где-то около 64 К обычно и получалось.
          Сейчас написал тест, действительно, примерно так и получается.

          Цитата TarasCo @
          WriteFile будет по скорости работать столько же ( при равных условиях ), разница в единицы процентов.

          Не согласен. Переписал функцию записи с использованием WriteFile и скорость подскочила раза в полтора. Возможно, потому, что не происходит создания объекта ядра "проекция файла"... Хотя, у меня его созданий не так много.
            Цитата Denny @
            Переписал функцию записи с использованием WriteFile и скорость подскочила раза в полтора


            1. возможно алгоритмы не равнозначны по сложности. Дело может быть и в многократном "перепроицировании". Кроме того, при работе с отображением на память содержимое отображение может сбрасываться более одного раза.

            2. обратите внимание на праметры открытия файла ( буферизация, последовательное чтение и.т.п. ). При определенном соотношении можно получить выигрыш и 20 раз, но это видимость, создаваемая системой кеширования.
            0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
            0 пользователей:


            Рейтинг@Mail.ru
            [ Script execution time: 0,0204 ]   [ 16 queries used ]   [ Generated: 2.05.24, 20:32 GMT ]