Самый быстрый способ работы с фалами?

← →
serejka (2009-06-27 14:11) [0]

Доброго выходного дня всем!
Открытие/чтение/запись?

← →
Andy BitOff © (2009-06-27 14:14) [1]

С фалами говоришь... =)))))

← →
serejka (2009-06-27 14:16) [2]

> Andy BitOff © (27.06.09 14:14) [1]

:)
дельфовые assign/read\write или лучше winApi поглядеть? Наскока второй способ быстрее?

← →
Rouse_ © (2009-06-27 14:24) [3]

assign/read\write тоже работает через WinAPI так что тут ты скорости не найдешь.

← →
serejka (2009-06-27 14:27) [4]

> Rouse_ © (27.06.09 14:24) [3]
>
> assign/read\write тоже работает через WinAPI так что тут
> ты скорости не найдешь.

Спасибо за разьяснение... судя по: что тут
> ты скорости не найдешь.
где-то ее найти можно?
:)

← →
boa_kaa © (2009-06-27 14:43) [5]

а что такое самый быстрый?

← →
@!!ex © (2009-06-27 15:01) [6]

> [4] serejka (27.06.09 14:27)
> где-то ее найти можно?

Прямая запись и чтение на диск? Не будет заметно быстрее, кстати.

← →
DrPass © (2009-06-27 15:09) [7]

> serejka (27.06.09 14:11)
> Доброго выходного дня всем!
> Открытие/чтение/запись?

Когда придумаешь какой-либо иной способ работы с файлами, обязательно напиши

← →
AndreyV © (2009-06-27 16:12) [8]

Диск и так медленный.;)

← →
TIF © (2009-06-28 20:11) [9]

Насколько я знаю, зависит не от способа, а от количества байт, считываемых за раз :) То есть от винчестера (за каждый оборот постараться прочитать максимум информации, не заставляя крутиться его вхолостую)

← →
Бурундук (2009-06-28 22:06) [10]

Самый быстрый, по моему опыту - через Memory Mapped Files.

← →
Loginov Dmitry © (2009-06-28 23:24) [11]

> Самый быстрый, по моему опыту - через Memory Mapped Files.

Имхо: самый быстрый тот, в котором чтение/запись выполняется блоками не меньшими, чем размер дискового кластера. В Memory Mapped Files ничего такого волшебного то и нету ))

← →
тимохов © (2009-06-28 23:45) [12]

у Рихтера в "Программирование серверных приложений для Windows 2000" был пример с асинхронной работой с файлами. Я вот не буду утверждать, но асинхронность там вроде как (т.е. не уверен) позиционировалась как надежное средство увеличение производительности. Можно туда посмотреть. Да и вообще, книга полезная.

← →
Германн © (2009-06-29 00:36) [13]

> Rouse_ © (27.06.09 14:24) [3]
>
> assign/read\write тоже работает через WinAPI так что тут
> ты скорости не найдешь.
>

> DrPass © (27.06.09 15:09) [7]

+1
Все прочие ответы, мягко говоря, есть - "мысли вслух ни о чём".

← →
Вариант (2009-06-29 08:36) [14]

> Германн © (29.06.09 00:36) [13]

> Все прочие ответы, мягко говоря, есть - "мысли вслух ни
> о чём".

У тебя есть аргументы в поддержку твоего мнения например по [10] или [12],
или [13] -это "мысли вслух ни о чём"?

На мой взгляд - вопрос ни о чем, ибо работа с файлами не всегда ограничивается простым понятием открыл/ закрыл/ записал и может иметь свою логику работы, от которой много зависит. Не расскрыт вопрос до конца, из-за чего любой ответ может оказаться ни о чем, каким бы квалифицированным он не был.
Если хочешь помочь автору - научи задавать вопросы, задай сам наводящие. Хочешь отсечь неверное - аргументируй почему, если нет аргументов, а есть мнение, чувство - пиши, что это мнение, твой опыт.
Не хочешь сам, зачем отбиваешь охоту у других?

← →
Дуб © (2009-06-29 08:48) [15]

> Вариант (29.06.09 08:36) [14]
>
> > Германн © (29.06.09 00:36) [13]
>
>
> > Все прочие ответы, мягко говоря, есть - "мысли вслух ни
>
> > о чём".
>
> У тебя есть аргументы в поддержку твоего мнения например
> по [10] или [12],
> или [13] -это "мысли вслух ни о чём"?

Оставь старика в покое. У него обычный утренний губокий лизун. Ну и маразм.

← →
Alex Konshin © (2009-06-29 09:37) [16]

> Германн © (29.06.09 00:36) [13]
> > Rouse_ © (27.06.09 14:24) [3]> > assign/read\write тоже работает через WinAPI так что тут > ты скорости не найдешь.
> > > DrPass © (27.06.09 15:09) [7]+1Все прочие ответы, мягко говоря, есть - "мысли вслух ни о чём".

MemoryMappedFiles и/или асинхронное чтение/запись.
Это действительно существенно ускоряет обработку файлов во многих случаях, но особенно при больших объёмах. Но случаи бывают разные. Если конкретнее опишешь параметры и цикл обработки файлов, то предложим более конкретные пути оптимизации. Например, может оказаться, что ты не там ускоряешь, а надо подумать о железе (о рейде, например), или вообще ввод-вывод не является узким местом в твоем случае.

← →
Германн © (2009-06-30 02:45) [17]

> Дуб © (29.06.09 08:48) [15]
>
>

Про маразм я и сам знаю.
Но вот что есть "обычный утренний губокий лизун"? Объясни, пожалуйста, если не сложно конечно!
Завтра пойду в аптеку покупать лекарства от этого.
:)

> Alex Konshin ©

То, что Алекс может что-то сделать лучше, быстрее и т.п. никто не сомневается. Но к сабжу и к автору сабжа это не имеет никакого отношения.
Перечитайте сабж ещё раз, если не согласны со мной.

А. Ну да.
Есть ещё один вариант ответа на сабж. Дать готовый код, который "якобы" способен убыстрить работу с файлами.

← →
Вариант (2009-06-30 07:37) [20]

> Германн © (30.06.09 03:23) [19]

> Дать готовый код, который "якобы" способен убыстрить работу
> с файлами

.
Для одного из случаев, где автор (Рихтер) поставил себе задачу сделать " быструю работу c файлами" (быструю а не "якобы"), ссылка на готовый код и описание что и как работает дана в [12]. А в другой книге, этот же автор (Рихтер) рассказывает о том, о чем говорил автор поста [10]. И тоже с примерами кода.
По

> Германн © (30.06.09 03:00) [18]

> Перечитайте сабж ещё раз, если не согласны со мной.

Ответ [16] очень уместен в теме сабжа на вопрос [4], в отличие от [13].

> Бурундук (28.06.09 22:06) [10]

> Самый быстрый, по моему опыту - через Memory Mapped Files.

http://groups.google.com/group/fido7.su.win32.prog/msg/14bb69b4dec1da1a

http://groups.google.com/group/fido7.su.win32.prog/msg/e4edc3fb35401f38

Т.е., смотреть надо и на цель.

--
Regards, LVT.

C Memory Mapped Files наткнулись на неприятную особенность.
Есть интенсивно использующиеся файлы, рандом чтение/запись. Они нужня для того, чтобы прога после падения стартанула с ближайшего места и далее поехала работать.

Перевели это дело на Memory Mapped Files. В тестах ускорение налицо.

Пустили в бой - выяснилось, что нагрузка на HDD выросла неимоверно. Убрали нафик.

Да, тесты ставили неудачно в смысле без учета всех боевых особенностей. Как именно сделано сейчас - не знаю, признаться.

Хотя я, конечно, не исключаю, что просто приготовили их неправильно.

← →
Бурундук (2009-06-30 18:25) [23]

> Leonid Troyanovsky © (30.06.09 14:53) [21]

Просто обычно проблемы с производительностью возникают
при работе с большими файлами. По крайней мере, у меня.
:-)))

А в целом, конечно, многое зависит от задачи.

← →
Дмитрий Белькевич (2009-07-01 02:33) [24]

>Просто обычно проблемы с производительностью возникают
при работе с большими файлами.

Когда файлов по 200-300 кб несколько терабайт, тоже, знаете, мало приятного.

Самый быстрый способ работы с фалами? Найти похожие ветки