Конференция "Основная" » Перевод функций на asm для ускорения работы [D7, Win2k, WinXP]
 
  • Wolf © (05.01.08 17:52) [0]
    Приветствую.
    Пишу приложение функцией которого являеться сканирование всех файлов на диске и вывод информации о файлах. включая размер файла.

    Использую стандартные функции поиска и определения размера.
    Возникла идея ускорить работу путем написания функций на asm.
    Сам я асемблер знаю плохо.
    Может быть вы сможете помочь перевести функцию определение размера файла а asm ?

    Что то наподобие чтобы получилось

    function FileSize(FileName:string):integer; // возвращает размер файла в байтах
    begin

    asm
    // Код на asm
    end;

    end;

    Пока это самое основное. Еще бы кто нибудь подсказал как реализовать поиск файлов на asm и было бы вообще замечательно :)
  • @!!ex © (05.01.08 17:59) [1]
    > [0] Wolf ©   (05.01.08 17:52)

    Это глупо. Т.К, определение размера штука виндовая, и состоит лишь в вызове функции API. Соответственно что на Асме, что на дельфе, один и тот же код получится.
  • sniknik © (05.01.08 18:09) [2]
    > ... :integer; // возвращает размер файла в байтах
    размер файлов не более 2 гиг?
    типа "закладка" на дальнейшее, будет чего исправлять при сопровождении.

    совет хочеш? не парь мозги с таким "ускорением", основное ускорение в алгоритмах, в продуманной работе программы, а не в операциях над байтами...
    вот когда все остальные средства исчерпаны, а необходимо еще, хоть на пару процентов... вот тогда да.
    большого прироста производительности "корпление над байтами" не дает, чаще наоборот дает дополнительные тормоза...
  • tesseract © (05.01.08 20:49) [3]

    > Пишу приложение функцией которого являеться сканирование
    > всех файлов на диске и вывод информации о файлах. включая
    > размер файла.


    На Асм только гемор получишь. Быстрее нельзя. Маскимум что можно оптимизировать - вызовы сетевых функций, получишь минус посредника при операциях.
  • sniknik © (05.01.08 23:26) [4]
    > Быстрее нельзя.
    ?, ты же не знаеш КАК он там у себя написал. %)
    но раз потребовалось "ускорение" то подозреваю, что можно быстрее... но не за счет переписывания вызовов api на asm-е конечно.
  • DVM © (06.01.08 00:33) [5]
    Ловля блох.
  • Юрий Зотов © (06.01.08 03:58) [6]
    Есть легкое подозрение, что 90% времени в этой программе занимают дисковые операции - и никуда от этого не денешься.

    Оставшиеся 10% занимает собственно исполнение кода. И даже если это время оптимизировать до полного нуля, то суммарный выигрыш все равно не превысит 10%.
  • Германн © (06.01.08 04:47) [7]

    > Wolf ©   (05.01.08 17:52)


    > Еще бы кто нибудь подсказал как реализовать поиск файлов
    > на asm и было бы вообще замечательно :)
    >

    Забудь. То бишь плюнь на всё это!!!
  • Riply © (06.01.08 10:18) [8]
    > [6] Юрий Зотов ©   (06.01.08 03:58)
    > Есть легкое подозрение, что 90% времени в этой программе
    > занимают дисковые операции - и никуда от этого не денешься.
    Процент зависит от типа и критериев поиска.

    > Оставшиеся 10% занимает собственно исполнение кода.
    > И даже если это время оптимизировать до полного нуля,
    > то суммарный выигрыш все равно не превысит 10%.

    Очень сильно зависит от структуры дерева (количество детей в корне объекта и т.д.)
    При простом перечислении объектов файлового типа,
    на индексированном диске можно добиться выигрыша в 30 - 50%,
    если же при перечислении требуется еще и открытие файлов, то выигрыш в 2-3 раза.
  • Riply © (06.01.08 10:24) [9]
    > [8] Riply ©   (06.01.08 10:18)

    Забыла добавить: отнюдь не последнюю роль в ускорении играет
    уменьшение количества обращений к диску при сканировании,
    по сравнению с тем количеством, которое потребуется если использовать FindFirst/FindNext
  • @!!ex © (06.01.08 10:47) [10]
    > [9] Riply ©   (06.01.08 10:24)

    Вопрос в том, что ассемблер тут никак не поможет, :)
  • Riply © (06.01.08 10:57) [11]
    > [10] @!!ex ©   (06.01.08 10:47)
    > Вопрос в том, что ассемблер тут никак не поможет, :)

    Вот с этим не могу не согласиться :)
    Тем более, что автор хочет получать размер файла,
    не при нахождении оного, а его повторным открытием.
    Иными словами: повтрорным поиском :)
  • DVM © (06.01.08 11:40) [12]

    > Riply ©   (06.01.08 10:57) [11]


    > Вот с этим не могу не согласиться :)

    Что такого можно сделать на ASM, чего бы нельзя было сделать на Pascal-е, чтобы код на ASM был существенно быстрее, чем на Pascal? Применительно к данному случаю.
  • @!!ex © (06.01.08 11:44) [13]
    > [12] DVM ©   (06.01.08 11:40)

    Так Riply наоборот согласна, что ассемблер тут не нужен... :)
  • DVM © (06.01.08 11:49) [14]

    > Так Riply наоборот согласна, что ассемблер тут не нужен.
    > .. :)

    :) а выглядит как наоборот. Многоуровневые отрицания однако.
  • Riply © (06.01.08 12:09) [15]
    > [14] DVM ©   (06.01.08 11:49)
    > :) а выглядит как наоборот. Многоуровневые отрицания однако.

    Sorry. Не всегда получается ясно излагать свои мысли :)
  • guav © (06.01.08 13:36) [16]
    > [0] Wolf ©   (05.01.08 17:52)

    Если FileSize вызывается исключительно для найденных файлов, то можно обойтись вообще без вызова FileSize.
    Структура WIN32_FIND_DATA, возвращаемая FindFirstFile, содержит размер, а также времена и аттрибуты.
    Это могло бы ускорить работу, особенно на FAT, но какие результаты будут на практике - не знаю, возможно, что в результате работы кэша они не будут ощутимыми.
    asm тут не при чём.
  • homm © (06.01.08 15:18) [17]
    > [14] DVM ©   (06.01.08 11:49)
    > :) а выглядит как наоборот

    Нет.
  • DVM © (06.01.08 16:10) [18]

    > Нет.

    Да.
  • homm © (06.01.08 16:13) [19]
    > [18] DVM ©   (06.01.08 16:10)
    > Да.

    Читаем фразу Riply еще раз, убеждаемся. Таки нет.
  • DVM © (06.01.08 16:15) [20]

    > homm ©   (06.01.08 16:13) [19]

    поспорить не с кем что ли? очевидно же, что я фразу прочитал бегло и мне показалось из-за обилия "не", что у неее противоположный смысл.
  • homm © (06.01.08 16:17) [21]
    > [20] DVM ©   (06.01.08 16:15)
    > очевидно же, что я фразу прочитал бегло и мне показалось
    > из-за обилия "не",

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


    > поспорить не с кем что ли?

    Это ты мне после [18] говоришь?
  • DVM © (06.01.08 16:23) [22]

    > homm ©   (06.01.08 16:17) [21]


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

    Я это все понял еще после [13] и твое замечание оно как бы запоздало.


    > Это ты мне после [18] говоришь?

    Да.
  • homm © (06.01.08 16:27) [23]
    > [22] DVM ©   (06.01.08 16:23)
    > Я это все понял еще после [13] и твое замечание оно как
    > бы запоздало.

    странно, в [13] понял, а в [18] опять не понял.
  • DVM © (06.01.08 16:30) [24]

    > странно, в [13] понял, а в [18] опять не понял.

    Согласен, тупую фразу "нет" я не понял.
  • homm © (06.01.08 16:34) [25]
    > [24] DVM ©   (06.01.08 16:30)
    > тупую фразу "нет" я не понял.

    Что там было не понять…
    И каким образом «фраза» «нет» может быть тупой…
  • DVM © (06.01.08 16:39) [26]

    > Что там было не понять…

    Мысль не развита. Подробнее надо.


    > И каким образом «фраза» «нет» может быть тупой…

    Поверь мне, может.
  • Wolf © (06.01.08 18:43) [27]
    > guav ©   (06.01.08 13:36) [16]

    Если FileSize вызывается исключительно для найденных файлов, то можно обойтись вообще без вызова FileSize.
    Структура WIN32_FIND_DATA, возвращаемая FindFirstFile, содержит размер, а также времена и аттрибуты.

    Спасибо за конкретную подсказку, действительно занимает время так же получения размера, нужно будет переделать

    Спасибо остальным :)
 
Конференция "Основная" » Перевод функций на asm для ускорения работы [D7, Win2k, WinXP]
Есть новые Нет новых   [133939   +174][b:0][p:0.001]