1 | |
Быстрое чтение файла11.11.2011, 10:59. Показов 19076. Ответов 71
Метки нет (Все метки)
Здраствуйте. Я пишу программу, которая читает файлы порядка от нескольких килобайтов до максимум 3 Мб. Посоветуйте пожалуйста, какие функции и/или алгоритмы использовать для максимальнобыстрого чтения данных, представленных вещественными числами. Прошу прощения, если мой вопрос неправильно сформулирован.
3
|
11.11.2011, 10:59 | |
Ответы с готовыми решениями:
71
Быстрое чтение массива из файла Быстрое чтение и запись файлов Быстрое заполнение большого файла Быстрое преобразование фурье wave файла |
278 / 173 / 21
Регистрация: 10.07.2011
Сообщений: 441
|
||||||
11.11.2011, 19:14 | 41 | |||||
теперь я не могу собрать. говорит:
error: ‘FILE’ has no member named ‘bsize’| в строке
Не по теме: talis
0
|
talis
|
11.11.2011, 19:15
#42
|
0
|
Диссидент
27706 / 17322 / 3812
Регистрация: 24.12.2010
Сообщений: 38,979
|
|
11.11.2011, 19:54 | 45 |
Странно...
В более свежих компиляторах (5.02 BCB-6) в хедере stdio.h в структуре FILE всюду есть член bsize а свежее у меня нет, я - ретроград. Добавлено через 13 минут У Qt вместо bsize - _bufsize Видать разные компиляторы по-разному называют поля структуры FILE. Мол нечего вам, прикладникам, со своим рылом в наши хедеры лезть. Но вы не волнуйтесь, эту строчку можно вообще убрать, это так, для наглядности Добавлено через 2 минуты Ничего, главное, что истина торжествует.
2
|
11.11.2011, 20:09 | 46 | |||||
Хорошо, давайте вместе. Обе функции Copy1 и Copy2 используют один и тот же размер буфера (по-вашему), но почему время их работы в разы отличается?
2
|
5828 / 3479 / 358
Регистрация: 08.02.2010
Сообщений: 7,448
|
|
11.11.2011, 20:19 | 47 |
Ну почему "старый"? Это корректный сишный код.
Код
[nameless@desktop c]$ gcc --version gcc (GCC) 4.6.1 20110908 (Red Hat 4.6.1-9) Copyright (C) 2011 Free Software Foundation, Inc. Это свободно распространяемое программное обеспечение. Условия копирования приведены в исходных текстах. Без гарантии каких-либо качеств, включая коммерческую ценность и применимость для каких-либо целей. [nameless@desktop c]$ cat main.c #include <stdio.h> main(void) { return foo(3); } foo(number) int number; { return printf("%d\n", number); } [nameless@desktop c]$ make gcc -Wall -ansi -pedantic -pedantic-errors -c -o main.o main.c main.c:3:1: предупреждение: по умолчанию возвращаемый тип функции - «int» [-Wreturn-type] main.c: В функции «main»: main.c:5:5: предупреждение: неявная декларация функции «foo» [-Wimplicit-function-declaration] main.c: На верхнем уровне: main.c:8:1: предупреждение: по умолчанию возвращаемый тип функции - «int» [-Wreturn-type] gcc -o sample main.o [nameless@desktop c]$ ./sample 3 [nameless@desktop c]$
0
|
В астрале
8049 / 4806 / 655
Регистрация: 24.06.2010
Сообщений: 10,562
|
|
11.11.2011, 20:37 | 49 |
-=ЮрА=-, Дык одно дело работа с потоками через Си-стайл, другое дело работа с классами. Естественно scanf работает быстрее. Но fstream куда удобнее и все таки С++, а не Си.
0
|
11.11.2011, 20:59 | 50 |
Буферизация всегда есть в текстовом и двоичном формате, теперь я это вижу. Но тогда как свой буфер точно такого же размера (а то и меньшего) в разы ускоряет процессы. Вот если встроенный буфер отключить, то собственный буфер сходит на нет.
2
|
Заблокирован
|
|
11.11.2011, 21:54 | 51 |
- представим ситуацию когда работаем с файлом который записан на съёмный носитель, например атавизм съёмных носителей -Дискетка 3,5(побитая, затёртая такая), ну или поближе к реалиям - подёртый вусмерть CD, так вот такой файлик лучше запихнуть поскорее в буферок, нежели скорее всего догробить дискетку или изи за неизбежного расстрекивания CD потерять поток где нибудь на середине диска - ну вот вставили мы его неудачно как раз на грани потери инфы на нём. Считать в буфер - это единственный вариант оставить съёмный носитель в покое и возможно отработать с инфой на съёмнике ещё разок...
PS:Я творил во время когда даже CDRW были роскошью - и с потерей данных ознакомлен так хорошо, что предпочту поскорее всё куда нибудь побыстрому считать, нежели издеваться fscanf-ом.
0
|
Диссидент
27706 / 17322 / 3812
Регистрация: 24.12.2010
Сообщений: 38,979
|
|
11.11.2011, 22:15 | 52 |
Видимо fread не просто пересылает несколько байт из буфера, а еще о чем-то напряженно думает, потому лучше к нему обращаться пореже.
Так что мы оба оказались правы. что приятно. Итоги дискуссии 1. Буфер создается для любого потока, если для его уничтожения не предпринимать специальных мер. 2. Тем не менее, в критических по времени случаях следует создавать собственный буфер, чтобы пореже обращаться к функциям fread, fwrite Добавлено через 2 минуты Присоединяюсь. Из этого обсуждения нам удалось узнать кое-что новое и полезное.
2
|
11.11.2011, 22:18 | 53 |
Согласен, дело более хитро обстоит. Именно то обстоятельство, что свой буфер значительно ускоряет работу и сбило меня с толку, что при этом автоматический буфер почти бездействует. Но благодаря этой теме понимаю, что все не так просто устроено. По поводу как раз вашего пункта 2. Почему так оказывается, что свой собственный буфер (даже меньшего размера) так все ускоряет. Это самый тонкий момент для меня оказался.
1
|
11.11.2011, 22:59 [ТС] | 60 |
Юра, смотри че получилось когда я сделала на 40 дублей ~240 Mb :
strtok быстрее! 35 vs 26
1
|
11.11.2011, 22:59 | |
11.11.2011, 22:59 | |
Помогаю со студенческими работами здесь
60
Максимальное быстрое создание большого файла Быстрое считывание 32кб из файла 7гб Быстрое создание пустого файла определенного размера Быстрое создание бинарного файла заданного размера Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |