Форум: "Основная";
Текущий архив: 2008.10.12;
Скачать: [xml.tar.bz2];
ВнизПеревод функций на asm для ускорения работы Найти похожие ветки
← →
Wolf © (2008-01-05 17:52) [0]Приветствую.
Пишу приложение функцией которого являеться сканирование всех файлов на диске и вывод информации о файлах. включая размер файла.
Использую стандартные функции поиска и определения размера.
Возникла идея ускорить работу путем написания функций на asm.
Сам я асемблер знаю плохо.
Может быть вы сможете помочь перевести функцию определение размера файла а asm ?
Что то наподобие чтобы получилось
function FileSize(FileName:string):integer; // возвращает размер файла в байтах
begin
asm
// Код на asm
end;
end;
Пока это самое основное. Еще бы кто нибудь подсказал как реализовать поиск файлов на asm и было бы вообще замечательно :)
← →
@!!ex © (2008-01-05 17:59) [1]> [0] Wolf © (05.01.08 17:52)
Это глупо. Т.К, определение размера штука виндовая, и состоит лишь в вызове функции API. Соответственно что на Асме, что на дельфе, один и тот же код получится.
← →
sniknik © (2008-01-05 18:09) [2]> ... :integer; // возвращает размер файла в байтах
размер файлов не более 2 гиг?
типа "закладка" на дальнейшее, будет чего исправлять при сопровождении.
совет хочеш? не парь мозги с таким "ускорением", основное ускорение в алгоритмах, в продуманной работе программы, а не в операциях над байтами...
вот когда все остальные средства исчерпаны, а необходимо еще, хоть на пару процентов... вот тогда да.
большого прироста производительности "корпление над байтами" не дает, чаще наоборот дает дополнительные тормоза...
← →
tesseract © (2008-01-05 20:49) [3]
> Пишу приложение функцией которого являеться сканирование
> всех файлов на диске и вывод информации о файлах. включая
> размер файла.
На Асм только гемор получишь. Быстрее нельзя. Маскимум что можно оптимизировать - вызовы сетевых функций, получишь минус посредника при операциях.
← →
sniknik © (2008-01-05 23:26) [4]> Быстрее нельзя.
?, ты же не знаеш КАК он там у себя написал. %)
но раз потребовалось "ускорение" то подозреваю, что можно быстрее... но не за счет переписывания вызовов api на asm-е конечно.
← →
DVM © (2008-01-06 00:33) [5]Ловля блох.
← →
Юрий Зотов © (2008-01-06 03:58) [6]Есть легкое подозрение, что 90% времени в этой программе занимают дисковые операции - и никуда от этого не денешься.
Оставшиеся 10% занимает собственно исполнение кода. И даже если это время оптимизировать до полного нуля, то суммарный выигрыш все равно не превысит 10%.
← →
Германн © (2008-01-06 04:47) [7]
> Wolf © (05.01.08 17:52)
> Еще бы кто нибудь подсказал как реализовать поиск файлов
> на asm и было бы вообще замечательно :)
>
Забудь. То бишь плюнь на всё это!!!
← →
Riply © (2008-01-06 10:18) [8]> [6] Юрий Зотов © (06.01.08 03:58)
> Есть легкое подозрение, что 90% времени в этой программе
> занимают дисковые операции - и никуда от этого не денешься.
Процент зависит от типа и критериев поиска.
> Оставшиеся 10% занимает собственно исполнение кода.
> И даже если это время оптимизировать до полного нуля,
> то суммарный выигрыш все равно не превысит 10%.
Очень сильно зависит от структуры дерева (количество детей в корне объекта и т.д.)
При простом перечислении объектов файлового типа,
на индексированном диске можно добиться выигрыша в 30 - 50%,
если же при перечислении требуется еще и открытие файлов, то выигрыш в 2-3 раза.
← →
Riply © (2008-01-06 10:24) [9]> [8] Riply © (06.01.08 10:18)
Забыла добавить: отнюдь не последнюю роль в ускорении играет
уменьшение количества обращений к диску при сканировании,
по сравнению с тем количеством, которое потребуется если использовать FindFirst/FindNext
← →
@!!ex © (2008-01-06 10:47) [10]> [9] Riply © (06.01.08 10:24)
Вопрос в том, что ассемблер тут никак не поможет, :)
← →
Riply © (2008-01-06 10:57) [11]> [10] @!!ex © (06.01.08 10:47)
> Вопрос в том, что ассемблер тут никак не поможет, :)
Вот с этим не могу не согласиться :)
Тем более, что автор хочет получать размер файла,
не при нахождении оного, а его повторным открытием.
Иными словами: повтрорным поиском :)
← →
DVM © (2008-01-06 11:40) [12]
> Riply © (06.01.08 10:57) [11]
> Вот с этим не могу не согласиться :)
Что такого можно сделать на ASM, чего бы нельзя было сделать на Pascal-е, чтобы код на ASM был существенно быстрее, чем на Pascal? Применительно к данному случаю.
← →
@!!ex © (2008-01-06 11:44) [13]> [12] DVM © (06.01.08 11:40)
Так Riply наоборот согласна, что ассемблер тут не нужен... :)
← →
DVM © (2008-01-06 11:49) [14]
> Так Riply наоборот согласна, что ассемблер тут не нужен.
> .. :)
:) а выглядит как наоборот. Многоуровневые отрицания однако.
← →
Riply © (2008-01-06 12:09) [15]> [14] DVM © (06.01.08 11:49)
> :) а выглядит как наоборот. Многоуровневые отрицания однако.
Sorry. Не всегда получается ясно излагать свои мысли :)
← →
guav © (2008-01-06 13:36) [16]> [0] Wolf © (05.01.08 17:52)
Если FileSize вызывается исключительно для найденных файлов, то можно обойтись вообще без вызова FileSize.
Структура WIN32_FIND_DATA, возвращаемая FindFirstFile, содержит размер, а также времена и аттрибуты.
Это могло бы ускорить работу, особенно на FAT, но какие результаты будут на практике - не знаю, возможно, что в результате работы кэша они не будут ощутимыми.
asm тут не при чём.
← →
homm © (2008-01-06 15:18) [17]> [14] DVM © (06.01.08 11:49)
> :) а выглядит как наоборот
Нет.
← →
DVM © (2008-01-06 16:10) [18]
> Нет.
Да.
← →
homm © (2008-01-06 16:13) [19]> [18] DVM © (06.01.08 16:10)
> Да.
Читаем фразу Riply еще раз, убеждаемся. Таки нет.
← →
DVM © (2008-01-06 16:15) [20]
> homm © (06.01.08 16:13) [19]
поспорить не с кем что ли? очевидно же, что я фразу прочитал бегло и мне показалось из-за обилия "не", что у неее противоположный смысл.
← →
homm © (2008-01-06 16:17) [21]> [20] DVM © (06.01.08 16:15)
> очевидно же, что я фразу прочитал бегло и мне показалось
> из-за обилия "не",
Очевидно же, что от того, как ты ее прочел, с фразой ничего не стновится, она как была верной, так и осталась.
> поспорить не с кем что ли?
Это ты мне после [18] говоришь?
← →
DVM © (2008-01-06 16:23) [22]
> homm © (06.01.08 16:17) [21]
> Очевидно же, что от того, как ты ее прочел, с фразой ничего
> не стновится, она как была верной, так и осталась.
Я это все понял еще после [13] и твое замечание оно как бы запоздало.
> Это ты мне после [18] говоришь?
Да.
← →
homm © (2008-01-06 16:27) [23]> [22] DVM © (06.01.08 16:23)
> Я это все понял еще после [13] и твое замечание оно как
> бы запоздало.
странно, в [13] понял, а в [18] опять не понял.
← →
DVM © (2008-01-06 16:30) [24]
> странно, в [13] понял, а в [18] опять не понял.
Согласен, тупую фразу "нет" я не понял.
← →
homm © (2008-01-06 16:34) [25]> [24] DVM © (06.01.08 16:30)
> тупую фразу "нет" я не понял.
Что там было не понять…
И каким образом «фраза» «нет» может быть тупой…
← →
DVM © (2008-01-06 16:39) [26]
> Что там было не понять…
Мысль не развита. Подробнее надо.
> И каким образом «фраза» «нет» может быть тупой…
Поверь мне, может.
← →
Wolf © (2008-01-06 18:43) [27]> guav © (06.01.08 13:36) [16]
Если FileSize вызывается исключительно для найденных файлов, то можно обойтись вообще без вызова FileSize.
Структура WIN32_FIND_DATA, возвращаемая FindFirstFile, содержит размер, а также времена и аттрибуты.
Спасибо за конкретную подсказку, действительно занимает время так же получения размера, нужно будет переделать
Спасибо остальным :)
Страницы: 1 вся ветка
Форум: "Основная";
Текущий архив: 2008.10.12;
Скачать: [xml.tar.bz2];
Память: 0.51 MB
Время: 0.04 c