есть код:


Здесь интересны всего три строки:


что бы их добавить, нужно подключить:


Можно, как  нибудь все это сделать одной командой??? может есть встроенная команда (для примера FileExists, определяет есть ли файл) для определения размера файла???

TFileStream::Size

знаю еще такие варинаты без доп подключений если есть vcl

или, с использованием GetFileSize, но ей всеравно нужен Handle файла:

по скорости приблизительно одинаково работают, второй процентов на 15 быстрей.

а что быстрее будет работать и стабильнее, прошлый код (см. выше) или новый???

новый код:


или вот этот код:

[/code]

Это сообщение отредактировал(а) Bima - 25.12.2006, 15:35

можно еще и через
FindFirstFile
FindClose
структура
WIN32_FIND_DATA .
DWORD    nFileSizeHigh; 
    DWORD    nFileSizeLow; 

#include <IdGlobal.h>

Size = FileSizeByName("test.txt");

Наверно это самый короткий код, но использовать компонент Indy(хотя я могу могу ошибаться), хм.

А все таки, что лучше использовать??? тут уже 4 реально работающих кода.
У меня приложение будет работать постоянно, то есть на серваке не меньше месяца. Код будет вызываться раз в минуту или реже.

по моим тестам получилось так:
самый быстрый вариант:
тот который в моем посте второй там где

потом около 15 % отставания от него способом fseek, 
далее приблизительно с отставанием 20-25% от первого идет способ с TFileStream,
c IdGlobal у меня не заработал начал ругаться на кругом расставленные GetTickCount();
вот так. пробовал вызывать функции на несколько тыс файлов никто не ругнулся. (хотя конечно проверки добавтить не помешало бы).

Любой из вышеприведённых примеров прицнипиально друг от друга ничем не отличается, на уровне системы всё сводится к CreateFile/GetFileSize(ну или аналогичные API). Так зачем использовать эти обёртки? Сразу вызывай соответствующие API, как показал codelord.

Это сообщение отредактировал(а) W4FhLF - 26.12.2006, 08:55

быстрее всего, по идее, должно быть таки через FindFirst, ибо при открытии файла все равно запись в каталоге читается.

FindFirstFile работает через пару функций ZwOpenFile/ZwQueryDirectoryFile. При этом уходит куча времени на преобразование ANSI строк в UNICODE и заполнении структуры WIN32_FIND_DATA. Другое дело, если сразу работать с FindFirstFileExW, тогда можно сэкономить кучу тактов.

Пара CreateFile/GetFileSize работает через пару функци ZwCreateFile/ZwQueryInformationFile, никаких заполнений структур здесь не происходит, но тоже много времени теряется на преобразовании ANSI > UNICODE.

Отсюда вывод, что оба примерно по скорости примерно одинаковы, если только использовать их W аналоги и работать с UNICODE строками. Быстрее тут ничего не придумаешь, ну разве что вызывать ядерные функции напрямую.

время выполнения непосредственно кода системных функций в данном случае не играет большой роли - основные задержки при обращении к диску(кэш не рассматриваем). предыдущий мой пост следует понимать именно в этом ключе - в какие дисковые операции "выливаются" эти варианты.

Так обращений к диску мы никак не избежим в любом случае, поэтому обсуждать это не имеет смысла. Лучше подумать как наиболее оптимально работать с функциями. Хотя, что тут думать и так всё ясно...

дык не про "избегание" речь, а про возможное сокращение количества обращений.
а что до скорости работы кода функций, то естественно, выигрывает CreateFile/GetFileSize(~32k/sec), чуть медленнее с vcl-обвеской(ввиду ее малого объема) в виде FileOpen/FileSeek(~30k/sec), и отчаянно тормозит FindFirstFile(~8k/sec). (note: кол-во естественно привязано к конфиге).

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

edit: "то естественно, выигрывает" - эт я, пожалуй, перевозбудился. нифига это не было очевидным, хотя интуитивно ZwQueryDirectoryFile немного настораживало... 

Это сообщение отредактировал(а) dumb - 27.12.2006, 05:11