процедура в отдельном потоке выполняется медленнее в 2 раза

← →
Johnny_Row (2006-08-09 20:40) [0]

Всем здрасьте. Не могу понять почему если процедуру запустить в отдельном потоке то она выполняется дольше в 2 с лишним раза. Даже с приоритетом TimeCritical. Может это естественно ?

делаю так:

вариант 1: (время выполнения ~10 сек)
begin
procedure1;
procedure2;
procedure3;
end;

вариант 2: (время выполнения ~20 сек)
begin
All:= TNewThread.Create (True);
All.FreeOnTerminate := True;
All.Priority:=tpTimeCritical;
All.Resume;
end;

procedure TNewThread.Execute;
begin
procedure1;
procedure2;
procedure3;
end;

Вопрос в следующем: или я неправильно че-то делаю или процедуры критичные к времени выполниния надо запускать в основном потоке, подскажите кто в курсе.

← →
Loginov Dmitry © (2006-08-09 20:45) [1]

> Не могу понять почему если процедуру запустить в отдельном
> потоке то она выполняется дольше в 2 с лишним раза. Даже
> с приоритетом TimeCritical. Может это естественно ?

Это естественно.

← →
Мефисто (2006-08-09 20:46) [2]

Для начала приведи нармальный код, а не абстракцию...
\Delphi\Help\Examples\Prgrsbar

← →
Leonid Troyanovsky © (2006-08-09 20:59) [3]

> Johnny_Row (09.08.06 20:40)

> Вопрос в следующем: или я неправильно че-то делаю или процедуры
> критичные к времени выполниния надо запускать в основном
> потоке, подскажите кто в курсе.

Прежде всего (вариант: поимимо всего) оно зависит
от кол-ва процессоров в системе.

--
Regards, LVT.

← →
Johnny_Raw (2006-08-09 21:14) [4]

Loginov Dmitry © говорит что это естественно, Мефисто видимо не согласен, просит привести нормальный код а не абстракцию, и дает ссылку на пример.
Я привел нормальный код, где здесь абрстракция, я же не помещю сюда код всех процедур которые там выполняются. А пример с прогресбаром посмотрел, и ничего показательного не увидел.

2Leonid Troyanovsky ©: в том то и вопрос, что если я сменю однопроцессорный комп на 2-х процессорный, и процессы запущу на разных процах, то в лучшем случае скорость останется такой же как если б я их запустил в основном потоке последовательно. Даже маленько в накладе останусь. или всетаки не так

← →
Мефисто (2006-08-09 21:22) [5]

> 2Leonid Troyanovsky ©: в том то и вопрос, что если я сменю
> однопроцессорный комп на 2-х процессорный, и процессы запущу
> на разных процах, то в лучшем случае скорость останется
> такой же как если б я их запустил в основном потоке последовательно.
> Даже маленько в накладе останусь. или всетаки не так

При верном подходе производительность увеличится. Но все равно конечное решение зависит от поставленной задачи.

← →
tesseract © (2006-08-09 21:39) [6]

> вариант 2: (время выполнения ~20 сек)
> begin
> All:= TNewThread.Create (True);
> All.FreeOnTerminate := True;
> All.Priority:=tpTimeCritical;
> All.Resume;
> end;

Видно же как день, на создание/завершении потока, что времени не тратиться??????.

Создание потока, выделение под него ресурсов - вещь небыстрая, и посему многие заранее создают потоки, а потом данные в них передают.

А так создай поток и измеряй время выполнения процедуры, в уже созданном потоке.

← →
Leonid Troyanovsky © (2006-08-09 21:42) [7]

> Johnny_Raw (09.08.06 21:14) [4]

> 2Leonid Troyanovsky ©: в том то и вопрос, что если я сменю
> однопроцессорный комп на 2-х процессорный, и процессы запущу
> на разных процах, то в лучшем случае скорость останется
> такой же как если б я их запустил в основном потоке последовательно.

Наклад, конечно, будет.
Но, изначально, в однопроцессорной системе, в одном потоке быстрей.

--
Regards, LVT.

← →
Johnny_Raw (2006-08-09 21:50) [8]

Всем спасибо за ответы, очень помогли

← →
Leonid Troyanovsky © (2006-08-09 21:52) [9]

> Leonid Troyanovsky © (09.08.06 21:42) [7]

> > однопроцессорный комп на 2-х процессорный, и процессы
> запущу
> > на разных процах, то в лучшем случае скорость останется
> > такой же как если б я их запустил в основном потоке последовательно.

> Наклад, конечно, будет.

Имел ввиду, что накладные расходы, конечно, будут, но,
с 2 процессорами, все равно, будет быстрей.

Sorry.

--
Regards, LVT.

← →
Мефисто (2006-08-09 21:53) [10]

> tesseract © (09.08.06 21:39) [6]

Хм... Телепатия? :) А я думал автор просто создал поток. Я вот ни гдебы не предположил (по посту выше), что он создает поток и уничтожает его по нескольку раз подряд (хотя помнится один создавал нейросеть из неодной сотни потоков :) ). А в примеры я его отравил по сие странному созданию потока в (> вариант 2:) (обычно такие штуки принято устанавливать в конструкторе потока).

По поводу большой разницы во времени, разницы быть не должно. Разница там мизер - доли секунды (исключение - если телепатия tesseract верна и поток создается/уничтожается по n количеству раз). Если такая большая разница, возникает вопрос. Выводят ли данные процедуры автора в компоненты VCL и как выполняется данная синхронизация с этими компонентами?

← →
tesseract © (2006-08-09 21:56) [11]

> Имел ввиду, что накладные расходы, конечно, будут, но,
> с 2 процессорами, все равно, будет быстрей.

Это только если данные у каждого потока СВОИ.

А вто если данные должны синхронизироваться между потоками?
вот тут и будет засада, так как идёт резкостное торможение, AMD64 побыстрее будет, sNuma позвоялет перебрасывать данные между процессорами с 40 % общей пропускной способностью, а Intel сдаёт вовсю.

← →
tesseract © (2006-08-09 22:00) [12]

> [10] Мефисто (09.08.06 21:53)

Иде телепатия ??????
смотрим код - в варианте 2 идёт создание потока, потом выполнение в execute+ FreeOnTerminate.

Время замера, как я понял, между созданием потока и его разрушением.

← →
Мефисто (2006-08-09 22:11) [13]

> tesseract © (09.08.06 22:00) [12]

У автора в (> вариант 2: ):

Создание потока в уснувшем состоянии. Далее установка нужных параметров потоку и собственно пробуждение потока.

А метод Execute для паказа, что начинка у него как в: варианте 1

> Время замера, как я понял, между созданием потока и его
> разрушением.

Даже если время замеряется в этих промежудках, размах времени слишком велик. Хотя, да конечно, нам не ведомо каков наследник от TThread и чего у него там еще в конструкторе/деструкторе создается/уничтожается. Но, как для самого простого наследника от TThread с одним перекрытым методом Execute - время создания/уничтожения - сущий мизер. Такчто, скорее всего у автора проблемы с кодом и поток тут не виновен ;)

← →
Johnny_Raw (2006-08-09 22:37) [14]

Ну я не знаю, какие а какие проблемы могут быть с кодом если, как я уже написал вначале, процедуры одни и те же. разница лишь в основном потоке или в новом они выполняются. В процедурах происходит парсинг xml файлов, и значения вносятся в строковые массивы. Еще эти значения и сообщения о ходе выполнения парсинга вносятся в стринггриды на форме. Поток я создаю один раз (а не многократно). Сейчас отключил вывод значений массива в грид. Время выполнения упало совсем незначительно. соотношение теперь составило 21500 к 49900 тикам. что даже больше чем с выводом значений на форму. Видимо всетаки так задумано, потому что в первом случае при нажатии на кнопку она даже не отжимается до завершения выполнения всех задач, в случае с новым потоком даже можно другие кнопки понажимать. )

> В процедурах происходит парсинг xml файлов, и значения вносятся
> в строковые массивы.

Массивы, как объявлены ? по каким потокам раскиданы? В потоке желательно использовать исключительно его переменные.

> Время выполнения упало совсем незначительно. соотношение
> теперь составило 21500 к 49900 тикам. что даже больше чем
> с выводом значений на форму.

Странно synchronize увеличивает вермя выполнения очень сильно ибо все операции с VCL выполняються в основном потоке.

> Видимо всетаки так задумано, потому что в первом случае
> при нажатии на кнопку она даже не отжимается до завершения
> выполнения всех задач, в случае с новым потоком даже можно
> другие кнопки понажимать. )

Это тоже грузит проц, не дёргайся, пока выполянется :-)

← →
Мефисто (2006-08-09 22:58) [16]

> что даже больше чем с выводом значений на форму.

Отменили вывод на гриды и производительность упала? Интересно...
Ну, незнаю. Тебе по твоему коду виднее ;)

← →
Мефисто (2006-08-09 23:04) [17]

> tesseract © (09.08.06 22:49) [15]

> Странно synchronize увеличивает вермя выполнения очень сильно
> ибо все операции с VCL выполняються в основном потоке.

Это точно. Можно сделать вывод данных через несколько проделанных операций (например через 20), а не через каждую подряд. Работа может пойти значительно шустрее.

← →
Johnny_Raw (2006-08-09 23:23) [18]

Почему упала. Время выполнения упало след. производительность повысилась! Это соотношение изменилось не в "+" доп. потока.Я походу понял в чем прикол: массивы объявлены глобально в модуле основной формы как Array of Array of String; наверно если их можно было бы объявить локально в потоке то было бы все ок.
ps. а synchronize я не делал (они как попало рисовались :))

← →
Johnny_Raw (2006-08-10 11:15) [19]

Сегодня решил все перепроверить и если кому интересно:

по отдельности процедуры в отдельном потоке выполнялись даже быстрее (примерно на треть). Таким образом нашел "тормознутую" процедуру и участок кода который по времени выполнялся как весь остальной код. Там создавался com-объект, а он сам по себе вроде новый поток создает. и видимо время тратилось на их синхронизацию.

вот это место:

CoInitializeEx(NIL, COINIT_MULTITHREADED); IDoc:=CreateComObject(Class_HTMLDOcument) as IHTMLDocument2; v:=VarArrayCreate([0,0],VarVariant); v[0]:= BCHTML; IDoc.write(PSafeArray(System.TVarData(v).VArray)) ; ElementCollection:= IDoc.all; {отсюда начинались тормоза} for k:=0 to ElementCollection.Length-1 do begin HtmlElement := ElementCollection.item(k, "") as IHTMLElement; if(HTMLElement.tagName = "TD")then begin S:=AnsiLowerCase(Trim(HTMLElement.Innertext)); while S<>""do begin BList:=GetWord(S); if BList<>"" then BBList.Add(BList); end; end; end;

процедура в отдельном потоке выполняется медленнее в 2 раза Найти похожие ветки