Текущий архив: 2003.03.03;
Скачать: CL | DM;
ВнизЧисто теоретический вопрос Найти похожие ветки
← →
nick-from (2003-02-15 22:39) [0]Есть алгоритм копирования директории (со всеми вложенными)
Он выполняется рекурсивно.
Если его распараллелить так чтоб для копирования каждой директории создавался свой поток, будет ли выйгрыш в скорости?
Вроде как-бы да (всетки паралельно ж), но в конечном итоге ведь работа идет с винтом, а не только в памяти; если запускать большое кол-во фоновых потоков копирования в том же windows comander - скорость копирования у них снижается, но ведь опять же, это мы не одну дирректорию копируем параллельно а разные.
Что кто скажет? Интересны ваши мнения
← →
Vitek (2003-02-15 22:58) [1]Это сколько же потоков надо?! Будет много времени уходить только на переключения между потоками :)
← →
Anatoly Podgoretsky (2003-02-15 23:14) [2]Чисто теоретический вопрос
Будет серьезный проигрыш, винчестер медленное устройство
← →
nick-from (2003-02-15 23:15) [3]Тоже фактор :)
← →
jack128 (2003-02-15 23:18) [4]А заодно объясните каким образом многопоточность (на однопроц машине) увеличивает производительность?
Какая разница как будут выполняться 2 функции : одна за другой или параллельно - выполняются, то они на одном процессоре, так что суммарное время выполнения в обоих случаях одинаковое...
← →
Anatoly Podgoretsky (2003-02-15 23:33) [5]jack128 © (15.02.03 23:18)
Она уменьшает
← →
sniknik (2003-02-15 23:34) [6]jack128 © (15.02.03 23:18)
чаще всего ~98% времени проги не работают а чегото ожидают, ввода, клика, события ....., почему бы это время не занять? именно для этого потоки и нужны.
← →
SPeller (2003-02-16 02:22) [7]
> А заодно объясните каким образом многопоточность (на однопроц
> машине) увеличивает производительность?
А вот таким образом, что один поток, выполняя одну функцию, не потребляет 100% процессорного времени, и поэтому невостребованное время можно отдать другому потоку на выплнение другой функции.
← →
SPeller (2003-02-16 02:24) [8]
> А вот таким образом, что один поток, выполняя одну функцию,
> не потребляет 100% процессорного времени
Обратное было в Win16 и DOS. Тогда во время выполнения одной программы все остальные останавливались ожидая её завершения. Таким образом, зависшая программа вешала всю систему.
← →
kaif (2003-02-16 03:05) [9]Я как-то был вынужден копировать файлы целыми директориями в связи с задачей. Так вот что интересно. Стандартная функция API CopyFile (или FileCopy, не помню...) работала удивительно медленно при большом количестве мелких файлов. Опыты проводились под NT4 (Server and workstations) в сети 100 Mbit. Обычное копированеие в Far-е шло намного быстрее. Погрузившись в проблему я обнаружил в Far-е опцию типа "использовать стандартную функуцию Win32 API при копировании файлов" (что-то в этом роде). Когда я включил этот флажок, Far стал копировать так же медленно, как моя программа. Любопытно, что мой напарник, работавший на С копировал файлы на великолепной скорости, сам не зная как, просто используя библиотеку cout самого С. Мне все это показалось крайне странным и я уже стал подумывать о функциях 16-разрядных (старых), которые есть в Win32 для совместимости...
Времени было крайне мало и я должен был срочно уехать из Москвы. Мы остановились на простом решении - я попросил напарника сделать dll на C, экспортирующую функцию копирования файла средствами cout, а я из дельфийской программы вызвал ее stdcall. Так мы тогда вышли из положения, тем более, что мы много написали тогда всяких dll на С и на Delphi и это не выглядело, как что-то особенное...
Но вопрос у меня так и остался. Почему обычная функция копирования файлов, являющаяся стандартной в Win32 API нас тогда так подвела при работе в сети?
Если кто знает ответ - я был бы весьма признателен...
← →
igorr (2003-02-16 05:25) [10]to kaif © (16.02.03 03:05)
Может быть из-за того, что в Windows нет
ограничений в размере имени?
← →
[NIKEL] (2003-02-16 16:30) [11]использование потоков для операций поиска - будут одни тормоза
это если ты ищешь файлы например в сети(локальной) - то тогда можно подумать о потокаха для каждой шары
а поиск файлов на дисках происходит очень и очень быстро - и не надо никаких потоков - 2-5 с. и все нужные файлы на одном диске найдены, проверено.
Страницы: 1 вся ветка
Текущий архив: 2003.03.03;
Скачать: CL | DM;
Память: 0.47 MB
Время: 0.009 c