| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Увеличится ли скорость в моём случае если я сделаю 2 потока? [D7, WinXP]
rolex © (2005-03-08 18:45:00)Моя прога предположим ищет файлы на винте. Увеличится ли скорость общего поиска, если я его разобью на 2 потока?
Palladin (2005-03-13 15:02:00) [41]
> [44] Дмитрий Мыльников
Программа должна читать данные из COM порта и обрабатывать файлы. В COM порте данных нет. Программа ждет данные, но файлы не обрабатывает. Потому что поток один. Процессор один. Тут какой то дебил решил погнаться за "модной фишкой". Решил сделать два потока. Один будет заниматся чтением данных из COM порта, другой обрабатывать файлы. Блин, как хорошо получилось то. И файлы обрабатываются и программа не висит при отсутствии данных в COM. И тут он прочитал твой пост и прозрел. В срочном порядке вернул один поток. Ведь, как сказал Дмитрий Мыльников, все что он увидел при двух потоках оказалось иллюзией и неправдой...
Anatoly Podgoretsky (2005-03-13 14:48:00) [42]То что криво, так сразу сказали не в потоках счастье.
Дмитрий Мыльников (2005-03-13 14:39:00) [43]Да при чём тут вообще многопоточность, если базовый алгоритм написан криво, с постоянным обращением к визуальной части, которые вызывают весьма длительную перерисовку компонетов?
Тут хоть один поток, хоть два, хоть сто, толку всё равно не будет. И даже если делать повторный поиск, то сокращения времени с 3 мин до 7 сек как у проводника тоже не будет, поскольку основное время тратится вовсе не на поиск или даже перемещение головок, а на постоянную перерисовку визуальной части.
И вообще, у меня после прочтения нескольких тем, в которых так или иначе обсуждается многопоточность, сложилось впечатление, что создание множества потоков стало эдакой модной фишкой, да ещё и обросшей массой мифов. Типа, вот сделаю приложение многопоточным, и сразу будет мне счастье. А о том, что на большинстве компьютеров стоит ТОЛЬКО ОДИН ПРОЦЕССОР, почему-то никто не вспоминает. Ведь в случае с одним процессором, ЛЮБАЯ МНОГОПОТОЧНОСТЬ ЛИШЬ ИЛЛЮЗИЯ. И все приемущества, которые она даёт, сводятся к тому, что при грамотном использовании потоков прорамму можно сделать более простой и понятной, переложив решение части проблем на менеджер процессов ОС. Для срверных приложений, да ещё запускаемых на многопроцессорных системах, там да, разница будет существенной. Но и в этом случае нужно весьма немало времени потратить на проектирование программы.
Anatoly Podgoretsky (2005-03-13 11:20:00) [44]Есть такая хорошая программа Проводник называется.
157 гб просканировала за 3 минуты, 282000 файлов. Повторный запуск 7 секунд.
Это тем кто не верит, что два потока сильно затормозят сканирование, наглядно видно, что почти все время приходится на перемещение головок, при втором запуске головки уже не двигаются.
rolex (2005-03-13 10:47:00) [45]Хм... на самом деле быстро!
Денч (2005-03-12 21:07:00) [46]
> В результате чего время сканирования увеличилось с 5мин.
> до 7мин. !!! =0
Вот так да!!! Есть такая прога, sequoiaview называется ( http://www.win.tue.nl/sequoiaview/), так у меня на сканирование диска объемом 13 Гб затратила около 20 секунд.
Может, попробовать asm поюзать?
rolex (2005-03-12 20:15:00) [47]Осуществил второй вариант (Сканирование в одном потоке, а обработка и интерфейс проги в другом потоке). В результате чего время сканирования увеличилось с 5мин. до 7мин. !!! =0
rolex (2005-03-12 20:14:00) [48]Осуществил второй вариант (Сканирование в одном потоке, а обработка и интерфейс проги в другом потоке). В результате чего время сканирования увеличилось с 5мин. до 7мин. !!! =O
vertal (2005-03-11 22:10:00) [49]Запускай процедуру поиска и анализа имен файлов в отдельном потоке. В ней не должно быть никаких обращений к интерфейсу, и эта процедура должна быть полностью изолированной от остальной программы (связь только черз параметры). При нахождении нового подходящего файла кидай его имя в потокобезопасную очередь. Прикладные программы видимо должны считать, что FindFirst/FindNext - это предел скорости, так что с этой стороны оптимизация вряд ли возможна. Вместо MatchesMask создавай заранее необходимое число объектов TMask. Если выяснится, что узкое место - в операции проверке соответствия множеству масок, то можно попробовать сделать процедуру формирования конечного автомата, который будет проверять имя файла на соответсвие сразу любой из масок. В главном потоке по таймеру опустошай потокобезопасную очередь и выводи ее содержимое в контрол.
А код из [22] выглядит просто жутко:
Дикие имена переменых, отсутствие изоляции от остальной программы и от интерфейса, ProcessMessages понатыкано везде, лишние операции в цикле...
Это по-моему проще переписать.
rolex (2005-03-11 18:55:00) [50]А второй вариант стоитосуществить?
Erik1 (2005-03-11 12:23:00) [51]Да что непонятного то? Например:
Form1.label14.Caption:=IntToStr(StrToInt(Form1.label14.Caption)+1);
Нахрен сносим и пишем Inc(Count); где Count: Integer;
Еще пример: Form2.ListBox1.Items[i] тоже убрать и заменить на TList в который заносим record. Надеюсь структуру record сам опишеш?!
ВСЕ ОБРЕЩЕНИЕ К VCL(Form, ListBox, пр..) ВЫКИНУТЬ!
Anatoly Podgoretsky (2005-03-11 12:06:00) [52]Как опять?
rolex (2005-03-11 11:21:00) [53]Ау!!! На вопросики то ответьте!!!
rolex (2005-03-10 19:06:00) [54]Тоесть второй вариант стоитосуществить?
> Все обащения к VCL придется выкинуть и заменить их перемеными.
Всмысле?
Erik1 (2005-03-10 13:43:00) [55]to rolex
Твои расждения правильны, если обработка занимает хотябы 500mc. К томуже такой подход позволит привести в порядок твой ужаствый код. Все обащения к VCL придется выкинуть и заменить их перемеными.
Digitman (2005-03-10 13:33:00) [56]
> rolex (08.03.05 18:45)
> Моя прога предположим ищет файлы на винте
ну и пусть себе ищет !
зачем каждый найденный файл тут же изображать юзеру ? вот это непонятно ..
ну сформируй ты данные все разом, а потом изобрази их юзеру готовыми ! зачем рисовать по одному элементу за одну итерацию-то ? вот это непонятно ..
rolex (2005-03-10 12:28:00) [57]Вернёмся к потокам.
Вот схема (по моим предположениям):
1) Сейчас прога так сканирует:
Сканирование |- - - - |
Др. обработка | - - - -|
2) Если сделать 2потока (1й на скан, 2й на др. обработку): Сканирование |---- |
Др. обработка | ----|
Т.е. в первом случае сканируется файл, прога ждёт; потом прога смотрит (проверяет) файл, "сканирование" ждёт.
Во втором случае, всё идёт параллельно и нету практически никаких ожиданий, ни с той стороны, ни с другой.
Вывод: Во втором случае времени на общее сканирование (включая обработку) потребуется времени почти в два раза меньше!
*Под обработкой понимается сверка имения файла со списком масок и т.д.
Правильны ли мои рассуждения???
Fay (2005-03-09 22:43:00) [58]Что-то не верится, что with-ом можно ускорить поиск.
Knight (2005-03-09 22:24:00) [59]На собственном опыте убедился, что всякие там Application.ProcessMessages и ProgressBar'ы, тормозят процесс в несколько раз... чем реже, тем быстрее... :)
Дмитрий Мыльников (2005-03-09 21:49:00) [60]Ну на счёт всякой оптимизации через with и прочее, это когда явные тормоза уберёшь. А так особо и не заметишь. :)
Во-первых, как уже было сказано, не нужно Application.ProcessMessages вызывать в каждом повторении цикла. Заведи счётчик, и в конце цикла напиши что-то типа
int(I);
if (i mod 100) = 0 then Application.ProcessMessages;
То есть, вызывай его один раз на 100 проходов цикла (оптимальное число подбирается путём натурных испытаний). Плюс, в конце функции тоже можно, поскольку она у тебя рекурсивная.
Кстати, от рекурсии я бы не стал отказываться, поскольку так код выглядит проще, а существенного ускорения на древовидной структуре всё равно с помощью других алгоримтов не получить. Зато код будет более сложным.
Во-вторых, и это на мой взгляд самое главное - желательно собрать всю информацию во внутренних переменных, а уже потом переносить их в компоненты форм. А если по логике программы это сделать нельзя, то при массовых операциях очень рекомендуется делать следующее
<компонент>.Items.BeginUpdate;
try
... тут вносим массовые изменения в Items
finally
<компонент>.Items.EndUpdate;
end;
Фишка в том, что после вызова BeginUpdate блокируется вызов обновления компонента на экране до тех пор, пока не будет вызвана EndUpdate, которая и отобразит все изменения сразу. А сейчас у тебя получается, что каждое добавление строки запускает весьма длительный код по обновлению компонента на экране.
| |
Страницы: 