TProcess и задержка перед запуском приложения

[Brainenjii]

Собственно - сабж... Есть проект, который запускает себя же с разными параметрами. На всех машинах отрабатывает нормально, но на одной между

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

  WriteLn('aProccess.Execute: ' + TimeToStr(Now));
  aProcess.Execute;
  WriteLn('aProccess.Executed: ' + TimeToStr(Now));


и

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

  WriteLn('Initialization: ' + TimeToStr(Now));
  Application.Initialize;


проходит секунд 10 ничего не деланья... Касперского отключали - не помогло, да и на всех остальных машинах Касперский стоит. В чём может быть проблема?

[Sergei I. Gorelkin]

Перед Application.Initialize выполняется код в секциях инициализации модулей...

[Brainenjii]

А можно как-нибудь посмотреть очерёдность выполнения Initialization части? А в идеале ещё и поправить ^_^

З.Ы. а ведь есть шанс, что задержка появляется и не в моём модуле? А в каком-нибудь UIB, VirtualTreeView и т.п. Коли так, то WriteLn('UnitName: ' + TimeToStr(Now)); blabla; WriteLn('Exit: ' + TimeToStr(Now)); не поможет? Как можно лучше определить источник?

[Sergei I. Gorelkin]

Чтобы посмотреть очередность, я бы скомпилировал в ассемблерный текст и посмотрел по слову "INITTABLE".
Ну а поправить - исходники вроде бы открыты

[Brainenjii]

Эм... Знать бы что править ^_^ И учитывая, что фраза "скомпилировал в ассемблерный текст" вгоняет в фрустрацию, подозреваю что не особо получится ^_^ Начинаю вытащить из всех своих юнитов Initialization и Finalization в процедуры Initialize и Finalize и потом в Initialization у myproj.lpr сделать что-то вроде Unit1.Initialize; Unit2.Initialize и т.д... Заодно получится, что сам буду "рулить" очерёдностью. Я прав? ^_^

[Vadim]

Brainenjii
Вообще-то код инициализации модулей выполняется в порядке их расположения в строке Uses. Может быть стоит просто ограничиться добавлением в код инициализации каждого модуля WriteLn(Файл, Сообщение)?

[Sergei I. Gorelkin]

Вообще-то код инициализации модулей выполняется в порядке их расположения в строке Uses.

Это в том идеальном и почти нереальном случае, когда модули друг друга не используют. А когда используют, то используемые инициализируются перед использующими. И этот порядок менять не стоит.

Может быть стоит просто ограничиться добавлением в код инициализации каждого модуля WriteLn(Файл, Сообщение)

Хорошая идея.

[Brainenjii]

Уже сделал так - во всех своих Unit'ах... Задержка есть везде, оказывается, но если на всех машинах она около 1 секунды (даже меньше), то на той машине - 10-30... Причём попадает она между WriteLn('Exit Unit1'); в одном и WriteLn('Enter Unit2') -в другом... И как теперь понять - где она? ^_^

[Vadim]

Unit2 использует какие-то модули, теперь надо смотреть их...

[Brainenjii]

Unit2 - первый графический модуль... В смысле с формой... Всё остальное использует то же, что и Unit1... Как там можно определить место возникновения задержки? ^_^
P.S. Притом! Unit2 использует Unit3, который инициализруется горРаздо позже 0.о А в unit2 initialization состоит только из

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

Initialization
  WriteLn('TFormAddRecord: ' + TimeToStr(Now));
  {$I bformaddrecordunit.lrs}
  WriteLn('Exit: ' + TimeToStr(Now));


[Vadim]

Brainenjii
Вот, к примеру, есть два модуля - unit1 и unit2, которые используют одни и те же модули. Стандартные модули Lazarus мы разбирать не будем, а разберём только те, которые напрямую к Lazarus'у не относятся. Например и там и там есть не относящиеся к Lazarus'у модули uib1 и uib2 (это я условно ). Пишем:

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

unit unit1;
interface
uses ..., uib1, uib2;
...
initialization
  WriteLn('unut1.ini');
finalization
  WriteLn('unut1.fine');
end.
end.


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

unit unit2;
interface
uses ..., uib1, uib2;
...
initialization
  WriteLn('unut2.ini');
finalization
  WriteLn('unut2.fine');
end.


Соответственно в модули uib1 и uib2 в секцию инициализации записываем вывод на экран названия этих модулей.
Что у нас должно получится:

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

Вывод на экран:
unit1.ini
uib1.ini
uib2.ini
uib2.fine
uib1.fine
unit2.ini
uib1.ini
uib2.ini
uib2.fine
uib1.fine


Я могу ошибится с порядком, но принцип такой - теперь мы видим, что в каком порядке происходит и можем точно определить, к какому модулю что принадлежит - к unit1 или к unit2.

[Brainenjii]

Я так и сделал... Вот мой вывод:

C:\Develop\Shedule\Modules>schedule.exe
BConstantUnit
BStringConstant
BQueryUnit: 13:29:04
Try connect to Database: 13:29:04
Connected to database: 13:29:04
Exit: 13:29:04
BFilterUnit: 13:29:04
Exit: 13:29:04
BEventUnit: 13:29:04
Exit: 13:29:04
BTasksUnit: 13:29:04
Exit: 13:29:04// ЗАДЕРЖКА
BFormAddRecordUnit: 13:29:05
Exit: 13:29:05
BFormOptionsUnit: 13:29:05
Exit:13:29:05
BFormAuthUnit: 13:29:05
Exit: 13:29:05
BFormSuspendUnit: 13:29:05
Exit: 13:29:05
BFormAddEventUnit: 13:29:05
Exit: 13:29:05
BFormFormReglamentUnit: 13:29:05
Exit: 13:29:05
BFormFinishUnit: 13:29:05
Exit: 13:29:05
BFormAddGroup: 13:29:05
Exit: 13:29:05
BFormAddStateUnit: 13:29:05
Exit: 13:29:05
BFormAddUserUnit: 13:29:05
Exit: 13:29:05
BFormUserControlUnit: 13:29:05
Exit: 13:29:05
BFormFilterForm: 13:29:05
Exit: 13:29:05
BReportsUnit: 13:29:05
Exit: 13:29:05
BFormTasksUnit: 13:29:05
Exit: 13:29:05
BFormAboutUnit: 13:29:05
Exit: 13:29:05
BFormVersionUnit: 13:29:05
Exit: 13:29:05
BClientUnit: 13:29:05
BFormMainFormUnit: 13:29:05
Exit: 13:29:05
BReglamentUnit: 13:29:05
Exit: 13:29:05
BUserUnit: 13:29:05
Exit: 13:29:05
BRecordUnit: 13:29:05
Exit: 13:29:05
BTimeThreadUnit: 13:29:05
Exit: 13:29:05
BFormSelectUnit: 13:29:05
Exit: 13:29:05
BCommonUnit: 13:29:05
Exit: 13:29:05
Heap dump by heaptrc unit
48134 memory blocks allocated : 9162002/9335080
48134 memory blocks freed : 9162002/9335080
0 unfreed memory blocks : 0
True heap size : 294912
True free heap : 317136
Should be : 294912
C:\Develop\Shedule\Modules>

При том в BFormAddRecord в Uses'ах:

Uses
Classes, SysUtils, LResources, Forms, Controls, Graphics, StdCtrls,
ComCtrls, ExtCtrls, Buttons, Dialogs, BConstantsUnit, BStringConstantsUnit,
BCommonUnit, BRecordsUnit, BUsersUnit;

И BRecordUnit, да и вообще много всего - инициализируется значительно позже... Правда у меня частое явление - использовать всеми BCommonUnit, у которого BFormMainUnit стоит в Uses'ах в Implementation части... Так делать не стоит, наверное... Но как ещё обновлять главную форму...