-
Приветствую.
Пишу приложение функцией которого являеться сканирование всех файлов на диске и вывод информации о файлах. включая размер файла.
Использую стандартные функции поиска и определения размера.
Возникла идея ускорить работу путем написания функций на asm.
Сам я асемблер знаю плохо.
Может быть вы сможете помочь перевести функцию определение размера файла а asm ?
Что то наподобие чтобы получилось
function FileSize(FileName:string):integer; // возвращает размер файла в байтах
begin
asm
// Код на asm
end;
end;
Пока это самое основное. Еще бы кто нибудь подсказал как реализовать поиск файлов на asm и было бы вообще замечательно :)
-
> [0] Wolf © (05.01.08 17:52)
Это глупо. Т.К, определение размера штука виндовая, и состоит лишь в вызове функции API. Соответственно что на Асме, что на дельфе, один и тот же код получится.
-
> ... :integer; // возвращает размер файла в байтах
размер файлов не более 2 гиг?
типа "закладка" на дальнейшее, будет чего исправлять при сопровождении.
совет хочеш? не парь мозги с таким "ускорением", основное ускорение в алгоритмах, в продуманной работе программы, а не в операциях над байтами...
вот когда все остальные средства исчерпаны, а необходимо еще, хоть на пару процентов... вот тогда да.
большого прироста производительности "корпление над байтами" не дает, чаще наоборот дает дополнительные тормоза...
-
> Пишу приложение функцией которого являеться сканирование
> всех файлов на диске и вывод информации о файлах. включая
> размер файла.
На Асм только гемор получишь. Быстрее нельзя. Маскимум что можно оптимизировать - вызовы сетевых функций, получишь минус посредника при операциях.
-
> Быстрее нельзя.
?, ты же не знаеш КАК он там у себя написал. %)
но раз потребовалось "ускорение" то подозреваю, что можно быстрее... но не за счет переписывания вызовов api на asm-е конечно.
-
Ловля блох.
-
Есть легкое подозрение, что 90% времени в этой программе занимают дисковые операции - и никуда от этого не денешься.
Оставшиеся 10% занимает собственно исполнение кода. И даже если это время оптимизировать до полного нуля, то суммарный выигрыш все равно не превысит 10%.
-
> Wolf © (05.01.08 17:52)
> Еще бы кто нибудь подсказал как реализовать поиск файлов
> на asm и было бы вообще замечательно :)
>
Забудь. То бишь плюнь на всё это!!!
-
> [6] Юрий Зотов © (06.01.08 03:58)
> Есть легкое подозрение, что 90% времени в этой программе
> занимают дисковые операции - и никуда от этого не денешься.
Процент зависит от типа и критериев поиска.
> Оставшиеся 10% занимает собственно исполнение кода.
> И даже если это время оптимизировать до полного нуля,
> то суммарный выигрыш все равно не превысит 10%.
Очень сильно зависит от структуры дерева (количество детей в корне объекта и т.д.)
При простом перечислении объектов файлового типа,
на индексированном диске можно добиться выигрыша в 30 - 50%,
если же при перечислении требуется еще и открытие файлов, то выигрыш в 2-3 раза.
-
> [8] Riply © (06.01.08 10:18)
Забыла добавить: отнюдь не последнюю роль в ускорении играет
уменьшение количества обращений к диску при сканировании,
по сравнению с тем количеством, которое потребуется если использовать FindFirst/FindNext
-
> [9] Riply © (06.01.08 10:24)
Вопрос в том, что ассемблер тут никак не поможет, :)
-
> [10] @!!ex © (06.01.08 10:47)
> Вопрос в том, что ассемблер тут никак не поможет, :)
Вот с этим не могу не согласиться :)
Тем более, что автор хочет получать размер файла,
не при нахождении оного, а его повторным открытием.
Иными словами: повтрорным поиском :)
-
> Riply © (06.01.08 10:57) [11]
> Вот с этим не могу не согласиться :)
Что такого можно сделать на ASM, чего бы нельзя было сделать на Pascal-е, чтобы код на ASM был существенно быстрее, чем на Pascal? Применительно к данному случаю.
-
> [12] DVM © (06.01.08 11:40)
Так Riply наоборот согласна, что ассемблер тут не нужен... :)
-
> Так Riply наоборот согласна, что ассемблер тут не нужен.
> .. :)
:) а выглядит как наоборот. Многоуровневые отрицания однако.
-
> [14] DVM © (06.01.08 11:49)
> :) а выглядит как наоборот. Многоуровневые отрицания однако.
Sorry. Не всегда получается ясно излагать свои мысли :)
-
> [0] Wolf © (05.01.08 17:52)
Если FileSize вызывается исключительно для найденных файлов, то можно обойтись вообще без вызова FileSize.
Структура WIN32_FIND_DATA, возвращаемая FindFirstFile, содержит размер, а также времена и аттрибуты.
Это могло бы ускорить работу, особенно на FAT, но какие результаты будут на практике - не знаю, возможно, что в результате работы кэша они не будут ощутимыми.
asm тут не при чём.
-
> [14] DVM © (06.01.08 11:49)
> :) а выглядит как наоборот
Нет.
-
> Нет.
Да.
-
> [18] DVM © (06.01.08 16:10)
> Да.
Читаем фразу Riply еще раз, убеждаемся. Таки нет.