Как высчитать время выполнения программы?

[kibernetics]

Привет!
Интресно узнать от каких факторов влияет скорость выполнения программы? Тип переменной, циклы, функции, опреаторы.
Т.е. есть ли какой-то предварительный подсчет уже имеющихся операторов и переменных, чтоб высчитать время выполнения? Для чего это нужно? Например, пишешь программу, обрабатываешь какойто тестовый файл, к примеру, в 500кб. Вроде всё работает, но стоит размер увеличить до 10Мб как скорость заметно падает. Причем всё еще и виснет капитально.
Для примера у меня есть гиговый файл и мне нужно на нём применить такой алгоритм:
1. читаем сначала 4 байта (офсет 0)
2. ищем такую последовательность дальше по файлу
3. если найдено, то считываем к этим четырем еще один байт, пятый (офсет 4). опять проверяем совпадение по файлу.
4. когда максимальное совпадение блоков заканчивается, то чиатем 4 байта уже не сначала, а с офсета +1 байт (офсет 1)
5. итогом будет результат о количестве одинаковых блоков их размер и место их расположения.
Просто хотелось бы узнать есть ли смысл связываться с такой работой? Насколько компьютер "задумается" при таких объёмах?

[Konst_One]

Код: Выделить всё

Dim tmr as Single

tmr=Timer

'Do somthing
.....



debug.Print Format(Timer-tmr, "0.00")

[Viper]

Во-первых,алгоритм довольно таки мутно сформулирован. Что с чем надо сравнивать? Два файла или содержимое файла с чем то еще?

На скорость влияет многое. Тип переменной например, количество циклов и так далее. Факторов много. Практически любую реализацию конкретного алгоритма можно как то ускорить. Практически всегда найдутся каие-нить нюансы... или применить другой, более быстрый алгоритм выполняющий то же самое другим способом. Вариантов масса.

[Lumen]

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

[kibernetics]

!Viper!

Во-первых,алгоритм довольно таки мутно сформулирован. Что с чем надо сравнивать? Два файла или содержимое файла с чем то еще?

Порой на самом деле тяжело изъяснится. Сравниваются блоки в одном файле. Для начала определимся, что блок это набор >1 байта. В данном случае 4 байта. Эти четыре байта берутся с начала файла и ищутся дальше до конца файла. Если такой блок найден на какомто смещении, то сначала файла уже бертся к блоку + 1 байт. Получается,
1. Взяли первых 4 байта 0х0000 - 0х0003
2. Ищем дальше по файлу этот образец, нашли к примеру на смещении 0х0100 - 0х0103
3. К искомому блоку прибавляем следущий байт, т.е. уже получается мы ищем 0х0000 - 0х0004
4. Проверяем на смещении 0х0100 - 0х0104 сходятся ли блоки, если да, то снова прибавляем еще один байт к началу, или 0х0000 - 0х0005
5. Опять проверяем искомый блок со смещением.
6. И так до тех пор, пока не выяснится максимальный размер совпадения.
7. В случае, если такой блок не найден, то начальное расположение блока меняем сдвигом на байт, т.е. уже ищем с 0х0001 - 0х0004
и опять по кругу

[Amed]

kibernetics, точно предсказать нельзя.
Можно порекомендовать следующее:
1. В цикле делать DoEvents, чтобы не так подвисало. Возможно, не при каждом проходе цикла, а при каждом сотом или тысячном - так будет быстрее.
2. Как только сделали DoEvents - вывести в метку на форме какое-то число, характеризующее прогресс. Можно прогрессбар туда-сюда гонять, как в Netscape.

4. Проверяем на смещении 0х0100 - 0х0104 сходятся ли блоки, если да, то снова прибавляем еще один байт к началу, или 0х0000 - 0х0005
5. Опять проверяем искомый блок со смещением.
6. И так до тех пор, пока не выяснится максимальный размер совпадения.

Не понял. Каков максимальный размер блока, который ищем в файле? Судя по тому, что я читаю, программа работает дико медленно. По-черепашьи.

Лучше опишите исходную задачу самым доходчивым образом (что дано, что требуется), попробуем подойти к проблеме с другой стороны.

[kibernetics]

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

[Viper]

позволю себе сформулировать задачу несколько по другому.
1. Имеется массив байтов. Имеется минимальный размер блока (в нашем случае это 4)
2. Также задаем позицию в массиве с которой начинаем работу и размер массива (или позизию за которой искать уже не надо. Одним словом задаем диапазон поиска.
3. Берем первый байт блока и начиная с первой позиции после конца блока (т.е. если блок начинается с 0 и имеет размер 4, то начинаем с 5 позиции) проверяем байты на совпадение с заданным байтом. Завершать такой поиск следует в позиции=размер массива - размер блока+1
4. Если значения байтов совпадают, то проверяем последующие байты до момента когда очередная пара байт не совпадет. Если количество совпавших пар равно или больше минимального размера блока, то мы свою задачу выполнили. Иначе продолжаем поиск дальше.
5. Если во всем диапазоне поиска нужных совпадений не было найдено, то смещаем начальную позицию на единицу и второй проход, третий и так далее пока не дойдем до конца диапазона.

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

Пара вопросов автору:

1. Размеры блоков кратны единице или может быть другому числу, т.е. в постановке задачи сказано, что блок может бывть равен 4,5 и так далее. Но если бы размеры блока были равны слову или двойному слову, т.е. 4,6, 8 и так далее или еще лучше 4, 8, 12... то скорость возросла бы в соответствующее количество раз.
2. Если найдены блоки достаточного размера, то что делаем дальше. Ищем еще совпадения? Ищем блоки большего размера или прекращаем поиск?

[kibernetics]

Вот более наглядная структура как это должно работать:
Первое, читаем 4 байта с начала файла:
это

Код: Выделить всё

33 C0 8E D0

.

2. Ищем в файле эту последовательность. Нашли на офсете 0x2A80

3. Снова возращаемся в начало файла и читаем еще один байт:

4. Проверем равен ли он байту по смещению 0х2А84

тут он равен. значит опять в начало и читаем следующий байт, это 00


5. Опять проверяем по смещению (0х2А85). Тоже равен, значит опять в начало.
6. Читаем еще один. Это 7С

7. Проверяем (0х2А86). Опа, не равен. Значит всё. Максимальный блок, который равен составляет 6 байт. И находится на смещении 0-0х0005 и 0х2А80-0х2А85
не равен

8. Ищем опять первые четыре байта дальше по файлу. Т.е. после офсета 0х2А85
9. Нашли схождение на офсете 0х141Е2.
10. И путём перебора каждого последующего байта, определяем, что максимальная схожесть равна 379 байт.


вот сам тестовый файл: http://gameprobe.at.tut.by/pics/tst.hex

[GSerg]

kibernetics
А не мог бы ты таки найти время и пересохранить все картинки в gif?

[GAGArin]

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

Вариант работающий линейно - прем по файлу, смотрим по 4 байта, для каждого найденного пишем в массивчик +1 на соответствующей позиции. Потом пробег по массивчику с выборкой блоков для которых значение вхождений больше 2. И уже только эти блоки обрабатывать.

Минус - держать огромный массив значений вхождений и один неизбежный проход по нему. Но на больших файлах этот проход абсолютно незаметен будет.

[kibernetics]

!Viper! слушай, ты вроде грил, что както юзал маппинг. в общем так это или нет, может еще кто-то заинтересуется по этому поводу, как видят эту проблему другие люди, и кстати, может эта инфа будет тебе полезна для того, чтобы сделать в кирпичах свою "стеночку": http://www.wasm.ru/forum//index.php?act ... 24&page=-1

[Viper]

Собственно в кирпичах модуль по файл-мэппингу уже с неделю как лежит