Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | |
[C++] И такие бывают 27.02.03 10:42 Число просмотров: 1052
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
> Очень тяжело найти текстовый файл больше, чем размер
> оперативки.
Пара пустяков. У меня тут валяется несколько XML-описаний...
> (Попробуйте пальчиками гигабайт забить.
Ну кто ж такие вещи пальчиками делает. Слава Богу, в UNIXах программ, генерящих текстовый выход, предостаточно.
|
|
<programming>
|
[C++] Помогите с эффективным алгоритмом 26.02.03 08:12
Автор: Темный Эльф Статус: Незарегистрированный пользователь
|
|
Есть файл А, нужно из него переписать строки в файл Б в обратном порядке, заранее спасибо
|
|
[C++] Задача вроде простая. 26.02.03 10:29
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Есть файл А, нужно из него переписать строки в файл Б в
> обратном порядке, заранее спасибо
1. Отхватить память = размеру файла.
2. Прочитать его в память.
3. Построить индексы (заменить '\n' на '\0' полезно будет по ходу)
4. Ну и записать в обратном порядке.
Если я правильно понял задачу и не заметил подвох.
Должно быть достаточно эффективно, по сравнению с поиском строк в файле в обратном порядке и записью их.
|
| |
[C++] Смотря насколько большой файл 26.02.03 14:08
Автор: amirul <Serge> Статус: The Elderman
|
> > Есть файл А, нужно из него переписать строки в файл Б
> в
> > обратном порядке, заранее спасибо
> 1. Отхватить память = размеру файла.
Если файл сильно большой - может не выйти, лучше отмэпить его в память. Тут кстати была когда-то дискуссия по поводу эффективности мэппинга (в майкросовтоском его варианте). Если файл ожидается не сильно большой, то лучше всего будет действительно выделить и считать.
> 2. Прочитать его в память.
> 3. Построить индексы (заменить '\n' на '\0' полезно будет
> по ходу)
Можно открывать файл как текстовый - все \n будут заменяться на \0 если я правильно понял документацию
> 4. Ну и записать в обратном порядке.
Можно не строить индексы, а искать strrchr с конца и сразу писать в другой файл
> Если я правильно понял задачу и не заметил подвох.
> Должно быть достаточно эффективно, по сравнению с поиском
> строк в файле в обратном порядке и записью их.
|
| | |
[C++] Смотря насколько большой файл 27.02.03 10:13
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Если файл сильно большой - может не выйти, лучше отмэпить
> его в память. Тут кстати была когда-то дискуссия по поводу
> эффективности мэппинга (в майкросовтоском его варианте).
> Если файл ожидается не сильно большой, то лучше всего будет
> действительно выделить и считать.
Очень тяжело найти текстовый файл больше, чем размер оперативки.
(Попробуйте пальчиками гигабайт забить. Да что там гигабайт - мегабайт попробуйте. При 100 знаков в минуту - 10000 минут - 166.(6) часов ~7 дней непрерывного стучания днем и ночью и пописать не отойти. А про гигабайт умолчим... Да, и компьютеры с оперативкой, размером меньше 100 мегабайт рассматривать не будем - не тот день на дворе.)
Даже если и больше оперативки - своп, как правило включен.
> Можно открывать файл как текстовый - все \n будут
> заменяться на \0 если я правильно понял документацию
Ну это смотря чем читать. Я имел ввиду залпом одним read`ом. Иначе другие проблемы...
> Можно не строить индексы, а искать strrchr с конца и сразу
> писать в другой файл
Это уж как удобнее.
Мэпить память в файл не имеет смысла - все равно те же операции.
Наилучший способ обработки файлов считывать их целиком - готов поспорить. Менше накладных расходов на вызов функции чтения при кусочной обработки. Если файл больше оперативки и работы с диском не избежать, то своп грамотнее дисковые операции обработает. К тому же обычно рабочие файлы не рабочем разделе на раиде типа 1 лежат, а своп на раид типа 0 направлен. Хочется, чтоб быстрее сработало, просто добавь модуль памяти - в оперативке уместится - в десяток раз быстрее будет. Писал я как-то библиотечку для работы с файлами базы данных таким образом (а не чтение по записям) - летала, как самолет.
Urix`у - пятерка, алгоритм простой и эффективный, вот только накладные расходы на позиционирование (lseek).
|
| | | |
[C++] Я ж не сам придумал, а на основе обсуждения и собственного опыта 27.02.03 12:11
Автор: amirul <Serge> Статус: The Elderman
|
> Даже если и больше оперативки - своп, как правило включен.
У меня он как раз выключен, хотя бы для того чтоб проги с XML-ным интерфейсом не сильно тормозили
> > Можно открывать файл как текстовый - все \n будут
> > заменяться на \0 если я правильно понял документацию
>
> Ну это смотря чем читать. Я имел ввиду залпом одним
> read`ом. Иначе другие проблемы...
Я тоже имел в виду залпом, но одним fread-ом.
> Мэпить память в файл не имеет смысла - все равно те же
> операции.
А вот эта тема как раз очень тщательно обсасывалась и не имеет смысла еще раз делать то же самое. Единственное резюме: мэппинг в майкрософтовской реализации ведет себя мягко говоря, странно. Здесь даже проходила фича еще по одному связанному с этим вопросу: если делать CreateFile без кэширования, то (не мои слова: почем купил - за столько и продаю - не проверял) скорость его обработки возрастает чуть ли не в 3 раза.
> Urix`у - пятерка, алгоритм простой и эффективный, вот
> только накладные расходы на позиционирование (lseek).
Это да
|
| | | |
[C++] И такие бывают 27.02.03 10:42
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
> Очень тяжело найти текстовый файл больше, чем размер
> оперативки.
Пара пустяков. У меня тут валяется несколько XML-описаний...
> (Попробуйте пальчиками гигабайт забить.
Ну кто ж такие вещи пальчиками делает. Слава Богу, в UNIXах программ, генерящих текстовый выход, предостаточно.
|
| | | | |
[C++] Разве что "бывают" 27.02.03 11:16
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 27.02.03 11:17 Количество правок: 1
|
> Пара пустяков. У меня тут валяется несколько
> XML-описаний...
Я не спорю с тем, что такие файлы бывают и их даже можно найти.
Но это редкость.
> Ну кто ж такие вещи пальчиками делает. Слава Богу, в UNIXах
> программ, генерящих текстовый выход, предостаточно.
И как часто такие файлы "переворачивать" надо?
Вы не пробовали просто прочитать документацию на несколько сотен килобайт, я уж про несколько сотен мегабайт не говорю.
И, вообще, когда речь идет о программе/алгоритме и не требуется заказчиком в постановке задачи ограничение на объем памяти, то в решении на это упор ставить не следует.
Даже если эта программа будет использоваться на практике на современных компьютерах, то для подавляющего большинства файлов она сработает. По крайней мере, я сомневаюсь, что когда-нибудь в процессе работы пользователь увидит сообщение типа: "Для обработки данного файла мало оперативной памяти, добавте, пожалуйста [столько-то] и повторите попытку".
|
| | | | | |
[C++] Ну собственно и документацию переворачивать очень редко приходится :-)) 27.02.03 12:03
Автор: amirul <Serge> Статус: The Elderman
|
> Я не спорю с тем, что такие файлы бывают и их даже можно
> найти.
> Но это редкость.
>
> > Ну кто ж такие вещи пальчиками делает. Слава Богу, в
> UNIXах
> > программ, генерящих текстовый выход, предостаточно.
>
> И как часто такие файлы "переворачивать" надо?
Как раз потому, что файл надо перевернуть - он скорее всего сгенеренный. Почти во всем, набранном человеком очень важен исходный порядок строк
А насчет большого файла. Это я с фаром намучался. Уж не помню стандартный просмотрщик или редактор, но он загоняет весь файл в память целиком, а мне иногда и бинарник надо подправить символ-другой
А вообще. Алгоритмы найдены. Дальше это простой флуд. Предлагаю закрыть
|
| | | | | | |
Согласен 27.02.03 17:15
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
