Attention waldo kitty and others with slow machines.

I added code for timing the reading of all compiler options and the rendering the GUI for them. It shows a MessageBox after reading and rendering.
It is enabled when Lazarus is built with define TimeAllCompilerOptions. Go to Tools -> Configure "Build Lazarus"
There "Edit Defines", add TimeAllCompilerOptions, click OK, check the newly added checkbox, and build Lazarus.

I am now testing with an old Pentium 2 machine, 233 MHz, 320 MB memory. OS is latest PCLinuxOS with LXDE window manager.
This PC is truely slow in today's standards, yet Lazarus is still quite usable there. Compilation of big projects takes time of course. Clean build of Lazarus itself takes > half an hour.

Now testing the reading of all options from FPC in the "Other" page of compiler options GUI:
In this slow machine the reading still takes less than a second! Sometimes it takes only half a second.
In waldo kitty's faster machine it took much longer. It means its Windows is badly screwed somehow.
The reading happens now when the "Other" page is opened for the first time in a Lazarus session. It may be useless if the user does not click the "All options" or "Defines" does not
matter if the reading is fast. The benefit is that "All options" GUI opens slightly faster because options are read already. Anyway, I guess will move reading back to the all opts GUI window.

Rendering the GUI takes 9 seconds which is too much of course. It is directly proportional to CPU speed (I think). I will work on the grid GUI later.

Regards,
Juha

P.S.
Computers are truely getting faster! This 233 MHz Pentium 2 machine is less than 20 years old (?) and was used for demanding CAD work in a big company. I added memory later, it had maybe 256 MB then, or less. When a designer got a faster 400 MHz P2 computer, people around the company came to see it because it was so extremely fast. It was ok for a CAD application then, why is it completely obsolete now? Computers are now 1000 times faster than they were just a while ago. Why programs are still slow? Why, oh why?

"Juha Manninen" wrote

In waldo kitty's faster machine it took much longer. It means its Windows is badly screwed somehow.

Windows executable startup *is* much slower than on Linux, because especially the Win32 subsystem is doing quite some house keeping with IPC, etc. there. I'm still looking forward to somewhen test the compiler on NativeNT which does not have that overhead :)

Why programs are still slow? Why, oh why?

Because programmers don't try to optimize for speed anymore since you just need to buy faster hardware to make the program run faster :/

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130820/a6b3277f/attachment.html>

My main machine is rather old, too, maybe 7 years:: AMD Phenom(tm) 8650 Triple-Core Processor

It reads the options in < 50 ms. Rendering the GUI takes 100 ms.

Juha

My main machine is rather old, too, maybe 7 years:: AMD Phenom(tm) 8650 Triple-Core Processor

AMD released it only 5 years ago. Time traveling?

It reads the options in < 50 ms. Rendering the GUI takes 100 ms.

Mattias

Oops. I bought it as an "old" used machine some 3 years ago. Maybe the ex-owner also didn't remember when he bought it.
Wow, it was almost new then.
There was an issue with the CPU cooling fan. It was often running at max. speed without a reason, making loud noise. Maybe that is why it was sold cheaply.
There was too much silicon paste under the CPU heatsink. It had dried and contracted in the middle and there was a gap between it and the CPU. I removed the excess paste, spread the remainder and the fan stopped shouting.
I believe this is a common problem with many computers. The CPUs generate so much heat that their cooling is a delicate matter.

Juha

Juha Manninen wrote

Attention waldo kitty and others with slow machines.

[...]

[...]

I for one would welcome having this info not as a 'message box' but rather as a status bar information (like ones you get on certain dynamic sites: this page was rendered in %d ms (options readout %d ms, render %d ms) ) (and an option to enable it or not, somewhere in Lazarus Tools).

Or have just the timing of reading fpc options added into the Help->About Lazarus? (and so just the rendering of options timed on the compiler pages and reported on the status bar)

My ?0.02p.

-L.

Juha Manninen wrote

I believe this is a common problem with many computers. The CPUs generate so much heat that their cooling is a delicate matter.

I need to clean my laptop every half year or so or otherwise the dust layer at the fan grid will be so thick that no air goes through anymore => heat shutdown when doing a grep -.-

Regards,
Sven

i added the define to my build script...

* TASK: build lazbuild, startlazarus and necessary tools...
* CMND: make OPT="-gl -gh -dHEAPTRC_WINDOW -dTimeAllCompilerOptions" lazbuild lcl basecomponents starter bigidecomponents lhelp

* TASK: Debug IDE
* CMND: lazbuild.exe --build-ide="-gl -gh -dHEAPTRC_WINDOW -dTimeAllCompilerOptions" --build-mode="debug ide"

as a test, i unloaded all non-essential apps and left only my avast anti-virus running...

my script says it takes 15 minutes 35 seconds for

make clean
tortoise update
and the two above make and lazbuild functions

then i started lazrus and went to Projects->Options->other... the window that popped up says

Reading compiler options took: 00:14.125

then i clicked on the [All options] button and the box that popped up says

Rendering compiler options GUI took: 00:00.157

i don't know if it matters that i opened my thunderbird and started writing this response before clicking OK on the first box once i accurately wrote the reading compiler options line...

:) i have a few boxes of similar hardware... one or two are still performing backend server functions and others are now (low end) firewall devices...

as i noted previously, it is likely a combination of my anti-virus scanning the executables during their startup... also, my firewall on this w2k box is the old Kerio Personal Firewall which performs a MD5 calculation on the executables when they are accessed... this is to provide notification of the executable having been changed from what it was previously... if one has not updated the executable, this affords them an indicator that something has changed it and its execution can be stopped before it possibly starts an infectious operation...

it is possible that the graphics card and drivers may also be involved in the speed of the rendering... this box has a decent opengl capable agp video card instead of one of the even older non-opengl PCI video cards i have laying about... i know that opengl doesn't come into play in this aspect but i'm looking at its greater processing power as compared to other video cards...

as sven stated, programmers simply do not code for speed any more... they don't even code of size, either... simply throw a faster CPU and more memory at the application to make it go faster :/

FWIW: the above is one of the major things i truly detest about so much of today's applications... i much prefer smaller, faster code which runs rings around bloated stuff on faster processors with more memory... if one can make their code scream on an old slow processor with (eg) 256M RAM, imagine how fast it will really be on a 2Ghz processor with 1G RAM in a straight comparison... leaving out things like pipelining, cache tuning and other tricks to make things run faster...

waldo kitty wrote

On 8/20/2013 09:13, Juha Manninen wrote:

[...]

On the other hand, since I ditched Ubuntu*, and installed Debian on my old-ish Dell Lattitude D600 (from back in 2006... 1.6GHz, 1GB RAM) every apt-get update it keeps getting faster ;) I am amazed :) (Windows required fresh reinstall after every major round (or 2) of updates, to keep it in semi runnable state without frustrating the hell out of me, and all I did run on it was Firefox (and antivirus) in the last days)

(*Ditched Ubuntu 'cause they insist(ed when I did that) on having kernels that required PAE to work, and won't boot on older hardware any more... haven't been looking back since, and now with MATE desktop 'stead of Gnome3, I got thatold warm fuzzy feeling of being in control, again ;) )

-L ;)

Quite amazing!
I thought GUI rendering is always slower than running "fpc -h". I understand the reasons you explained for slow startup times of processes, but such a huge slowdown is too much.

I am thinking now if this is only a sole exception and all other computers can run "fpc -h" in milliseconds.
If there are other computers with the same problem then I must put the reading code into a thread.
The thread would be started when options "Other" page is selected, just like now. Then it may be ready when user clicks the "All options" button, not adding any visible delay anywhere.

i don't know if it matters that i opened my thunderbird and started writing this response before clicking OK on the first box once i accurately wrote the reading compiler options line...

It does not matter. The fpc process had run already at that point.

Juha

it is pretty standard for this old AMD 2800+ system... at least for now, anyway...

i think the thread thing would be the better way to go... we will never know what may be going on on a user's machine... consider one that is swapping excessively, for instance...

i was looking more at the rendering process possibly having been run and just waiting to be displayed...

as another test: i just loaded task manager so i could watch memory usage... with all my normal tasks loaded... ~499460M used
started lazarus... followed same path as before... reading compiler options: 18 and something seconds rendering: .172

memory consumption in the above was negligible... i ran it again thinking that it would all be in the disk cache and thus load faster... lazarus loaded in less than half the time it did previously but reading the options still took 18 seconds... memory consumption is sitting at ~535235 now... up slightly from the 499xxx figure above...

considering that this is a 2Ghz (2083mhz) machine, i'm not sure where to look, really... PATA HD... defragged at least once a week...

maybe i'll try unloading avast and seeing what that gets me... i'm really loath to unload the firewall but that, too, can be done... i guess i'll just pull the network cable loose, first ;)

Could you also test without antivirus and could you also test a second time (so that the executable might now reside inside the cache).

Maybe I'll need to test this on my mobile development computer as well (800 MHz Intel Stealy processor, 1 GB RAM, Windows 7) ^^

Regards,
Sven

[...]

Could you also test without antivirus and could you also test a second time (so that the executable might now reside inside the cache).

i will try... currently i've just also had some weirdness come up and am having random reboots... but i lost a power supply the other day and it is possible that this used replacement one is not fully up to snuff and causing problems... i have to dig and see if i can find another one [sigh]... if it isn't one thing, it is another :?

Maybe I'll need to test this on my mobile development computer as well (800 MHz Intel Stealy processor, 1 GB RAM, Windows 7) ^^

i don't know if it is worth it but it may be desirable to build a table of machines with their necessary specifics to get an idea of what is really going on... i'm going to try my tests again in a bit after unloading everything and having the machine run only in its sunsuit ;)

waldo kitty wrote

On 8/21/2013 11:45, Sven Barth wrote:

[...]

after an all day battle, i have finally been able to get my workstation more operational and test further... it seems that my (old) firewall's executable protection may be "at fault" in this... i mentioned previously that it performs a (MD5) checksum calculation on binaries as they are started... if the checksum is different than that calculated previously, it will show a warning allowing you to continue (and save the new checksum) or to abort the starting of the binary...

after preventing all additional apps from starting, including my firewall and my avast anti-virus, i saw 1.047 seconds for the reading of the compiler options... unloading lazarus and immediately reloading it and trying again gave me a (cached) reading time of 00.047 seconds...

enabling my anti-virus did not increase the loading time appreciably...

so, there we are... anywhere from 14 to 18 seconds with my firewall's MD5 checksum calculation and comparison... about 1 second or less with out...

i guess this stands to reason with binary sizes of 5.5Meg (ppc386.exe)... it simply takes time to load and calculate a checksum on files that large...

X:\freepascal>dir fpc\trunk\bin\i386-win32
Volume in drive X is c0ffee
Volume Serial Number is DEAD-BEEF

Directory of X:\freepascal\fpc\trunk\bin\i386-win32

07/31/2013 12:38 <DIR> .
07/31/2013 12:38 <DIR> ..
07/31/2013 12:35 206,848 bin2obj.exe 07/31/2013 01:16 450,048 chmcmd.exe
07/31/2013 01:16 261,120 chmls.exe
07/31/2013 12:34 604,160 cldrparser.exe 07/31/2013 12:35 49,152 data2inc.exe 07/31/2013 12:35 93,696 delp.exe
07/31/2013 12:37 6,628,352 fp.exe
06/02/2013 14:27 7,110 fpc.cfg
07/31/2013 01:09 92,672 fpc.exe
07/31/2013 12:33 262,656 fpcjres.exe 07/31/2013 12:34 423,424 fpclasschart.exe 07/31/2013 12:34 896 fpclasschart.rst 07/31/2013 12:33 291,328 fpcmake.exe 07/31/2013 12:33 225,280 fpcmkcfg.exe 07/31/2013 12:33 3,139 fpcmkcfg.rst 07/31/2013 12:33 333,312 fpcres.exe
07/31/2013 01:10 190,464 fpcsubst.exe 07/31/2013 12:34 764,416 fpdoc.exe
07/31/2013 12:34 187,904 fpmc.exe
07/31/2013 12:34 787,968 fppkg.exe
07/31/2013 12:34 190,464 fprcp.exe
07/31/2013 12:34 319,488 h2pas.exe
07/31/2013 12:34 38,912 h2paspp.exe 07/31/2013 12:34 321,536 importtl.exe 07/31/2013 12:34 201,216 instantfpc.exe 07/31/2013 12:34 418,816 makeskel.exe 07/31/2013 12:34 849 makeskel.rst 07/31/2013 01:10 42,496 mkarmins.exe 07/31/2013 01:10 46,592 mkx86ins.exe 07/31/2013 12:34 313,344 pas2fpm.exe 07/31/2013 12:34 378,368 pas2jni.exe 07/31/2013 12:34 316,928 pas2ut.exe
07/31/2013 12:34 71,168 plex.exe
07/31/2013 12:35 44,544 postw32.exe 07/31/2013 01:12 5,753,344 ppc386.exe
07/31/2013 12:35 43,520 ppdep.exe
07/31/2013 01:10 3,726,848 ppudump.exe 07/31/2013 01:09 94,208 ppufiles.exe 07/31/2013 01:10 109,568 ppumove.exe 07/31/2013 12:35 199,168 ptop.exe
07/31/2013 12:35 302 ptop.rst
07/31/2013 12:34 87,552 pyacc.exe
07/31/2013 12:35 86,528 rmcvsdir.exe 07/31/2013 12:34 52,736 rmwait.exe
07/31/2013 12:35 187,392 rstconv.exe 07/31/2013 12:35 1,882 rstconv.rst 07/31/2013 12:34 252,416 unihelper.exe 07/31/2013 12:34 314,368 unitdiff.exe 07/31/2013 12:34 681 unitdiff.rst 06/02/2013 12:37 1,345 yylex.cod
06/02/2013 12:37 4,334 yyparse.cod 51 File(s) 25,484,858 bytes
2 Dir(s) 5,241,798,656 bytes free

X:\freepascal>

waldo kitty wrote

after preventing all additional apps from starting, including my firewall and my avast anti-virus, i saw 1.047 seconds for the reading of the compiler options... unloading lazarus and immediately reloading it and trying again gave me a (cached) reading time of 00.047 seconds...

This 47 ms is exactly one second less than the first value. Maybe you typed it wrong.
Still, it is a realistic value in a healthy machine. I also got smaller than 50 ms timings on my work machine with Linux. Quite a difference compared to 18 seconds.

Juha

I don't use the define, it should log to console, not dialog....

But normally on my system the time is not noticeable (100 ms, tops 150 ?)

Now I just experienced it taking about 3 or 4 seconds. win 32 vista

The system was particular busy (another fpc (different exe / different version) was running).
- using 1 of 2 cpu => but the other was idle, so enough cpu power
- still 1Gb of RAM free
- but it would have prevented anything useful being in the OS disc cache because it accesses plenty of other files
Everything on my system react nice and fine, except that tab ("other") took a few seconds

not typoed... i looked at the wrong number on the sheet i wrote them down on... the cached speed should have been 00:141...

Still, it is a realistic value in a healthy machine. I also got smaller than 50 ms timings on my work machine with Linux. Quite a difference compared to 18 seconds.

yeah... i've been trying to locate the setting in my firewall where i can turn that protection off but i haven't found it and i'm not sure i want it off just in case something does try to get loose during my network security investigations and research ;)

Sven Barth wrote

Maybe I'll need to test this on my mobile development computer as well (800 MHz Intel Stealy processor, 1 GB RAM, Windows 7) ^^

I've written a simple application that uses TProcess to start "fpc -i" and "fpc -h" and reads it standard and error output. The "fpc" executable can be passed as parameter.

On my above mentioned 800 MHz system "fpc -i" takes ~445ms and "fpc -h" ~540ms for a 2.6.2 fpc.exe. If I now use a 2.6.2 ppc386.exe (which is called by fpc.exe) the time is ~240ms and ~315ms respectively.

I've attached the lpr if someone wants to test him-/herself.

Regards,
Sven
-------------- next part --------------
program processtest;

{$mode objfpc}{$H+}
uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  SysUtils
  { you can add units after this }, process;
procedure ExecuteProcess(const aExecutable: String;
  const aArgs: array of String);
var
  p: TProcess;
  s: String;
  buf: array[0..1023] of Byte;
  start: TDateTime;
begin
  p := TProcess.Create(Nil);
  try
    p.Executable := aExecutable;
    for s in aArgs do
      p.Parameters.Add(s);
    p.Options := [poUsePipes];
    start := Now;
    p.Execute;
    while p.Running do begin
      if p.Stderr.NumBytesAvailable > 0 then
        p.Stderr.Read(buf, Length(buf));
      if p.Output.NumBytesAvailable > 0 then
        p.Output.Read(buf, Length(buf));
    end;
    while p.StdErr.NumBytesAvailable > 0 do
      p.Stderr.Read(buf, Length(buf));
    while p.Output.NumBytesAvailable > 0 do
      p.Output.Read(buf, Length(buf));
    Writeln('Duration: ', FormatDateTime('hh:nn:ss.zzz', Now - start));
  finally
    p.Free;
  end;
end;
var
  exe: String;
begin
  if ParamCount = 0 then
    exe := 'fpc'
  else
    exe := ParamStr(1);
  ExecuteProcess(exe, ['-i']);
  ExecuteProcess(exe, ['-h']);
end.

the possibility of slow access is why i originally requested a "please wait while acquiring options" popup window just to let us know what was going on... but if the process is going to go into a background thread, there's no real need for the box... even in my testing, loading lazarus with the default empty project and going directly to project settings -> other as quickly as i could, it still took some few seconds... my mouse has to walk a long way over this 1600x1200 screen ;)

FWIW: i just spent several hours moving some large files off this machine so i could perform a thorough defrag of this NTFS file system... have returned the machine to normal operations and just tested again... consistent 15.xxx load times even back to back without exiting lazarus... just canceling the panel, re-opening it and selecting other... the drive light doesn't even blink... not sure what to do to make it faster... not sure that it really matters, either...

waldo kitty wrote

blink... not sure what to do to make it faster...

Replacing Windows with Linux would make it faster. See my earlier timings for a much slower P2 233 MHz machine.
Sorry, I could not resist writing this... You may have other reasons for using Windows of course. :)

Juha

Juha Manninen wrote

On Thu, Aug 22, 2013 at 2:50 PM, waldo kitty wrote: > blink... not sure what to do to make it faster... Replacing Windows with Linux would make it faster. See my earlier timings for a much slower P2 233 MHz machine.

I *know* that process startup time on Windows is slower than on Linux. That's what I have written already in another mail in this thread though not in relation to Linux.

Sorry, I could not resist writing this... You may have other reasons for using Windows of course. :)

I'm using Windows on that machine, because Linux does not fully work there.

Regards,
Sven

saved as processtest.lpr... opened laz and opened a project... pointed to processtest.lpr and chose 'Application' when laz asked what kind of project... was 'Application' the proper project to choose?

also, i edited line 49 where the value of 'exe' is set to 'fpc' to put in the complete path and filename since there is no apparent path search or extension...

   exe := 'X:\freepascal\fpc\trunk\bin\i386-win32\fpc.exe'

running gives me the following in a popup box...

Process processtest raised exception class 'RunError(103)'.

    In file 'processtest.lpr' at line 39:
   Writeln('Duration: ', FormatDateTime('hh:nn:ss.zzz', Now - start));

clicking [Continue] gives me this in another popup box...

Project processtest raised exception class 'EInOutError' with message: File not open

    In file 'processtest.lpr' at line 39:
   Writeln('Duration: ', FormatDateTime('hh:nn:ss.zzz', Now - start));

clicking [Continue] gives me this in a final popup box...

An unhandled exception occurred at $004017E4:
EInOutError: File not open
$004017E4 EXECUTEPROCESS, line 39 of processtest.lpr $004018EA main, line 52 of processtest.lpr

thinking that it might be a path related problem, i copied fpc.exe and ppc386.exe into the same directory as this processtest project... then i was able to see processtest start fpc and fpc attempted to start ppp386.exe but i got the same outputs as above...

'Program' or 'Simple Program' would have been correct. Alternatively you could have compiled it on the command line as well...

That is only the fallback (as Lazarus does). 'fpc' will then be searched in %PATH%. Other executables can be supplied using a parameter (the first one is used) so that I need to compile the test program only once to test different executables.

Maybe you should have chosen 'Program' indeed. ^^ Alternatively add "{$apptype console}" at the top or disable GUI application in the project options.

Regards,
Sven

i went back and created a new project but chose 'Program' this time instead of 'Application' and that works much better...

X:\freepascal\projects\processtest>processtest
Duration: 00:00:04.750
Duration: 00:00:02.421

X:\freepascal\projects\processtest>processtest
Duration: 00:00:01.047
Duration: 00:00:01.063

X:\freepascal\projects\processtest>processtest
Duration: 00:00:00.921
Duration: 00:00:01.047

X:\freepascal\projects\processtest>processtest
Duration: 00:00:01.188
Duration: 00:00:01.219

X:\freepascal\projects\processtest>processtest
Duration: 00:00:01.047
Duration: 00:00:01.047

X:\freepascal\projects\processtest>processtest
Duration: 00:00:00.813
Duration: 00:00:00.922

X:\freepascal\projects\processtest>processtest
Duration: 00:00:01.265
Duration: 00:00:01.281

X:\freepascal\projects\processtest>processtest
Duration: 00:00:01.281
Duration: 00:00:01.078

so... i tried project -> options -> other again and got 14.906 and 16.205 on the two test runs i made... hummm... why just a huge difference in time??

i deleted the two exes (fpc and ppc386) i had copied to the project directory and specified the full path to fpc on the command line...

X:\freepascal\projects\processtest>processtest
\freepascal\fpc\trunk\bin\i386-win32\fpc.exe
Duration: 00:00:01.094
Duration: 00:00:03.281

X:\freepascal\projects\processtest>processtest
\freepascal\fpc\trunk\bin\i386-win32\fpc.exe
Duration: 00:00:01.031
Duration: 00:00:03.156

X:\freepascal\projects\processtest>processtest
\freepascal\fpc\trunk\bin\i386-win32\fpc.exe
Duration: 00:00:01.157
Duration: 00:00:02.859

X:\freepascal\projects\processtest>processtest
\freepascal\fpc\trunk\bin\i386-win32\fpc.exe
Duration: 00:00:01.047
Duration: 00:00:03.110

weird... but ok... so once more but directly to ppc386...

X:\freepascal\projects\processtest>processtest
\freepascal\fpc\trunk\bin\i386-win32\ppc386.exe
Duration: 00:00:00.500
Duration: 00:00:02.485

X:\freepascal\projects\processtest>processtest
\freepascal\fpc\trunk\bin\i386-win32\ppc386.exe
Duration: 00:00:00.610
Duration: 00:00:02.515

X:\freepascal\projects\processtest>processtest
\freepascal\fpc\trunk\bin\i386-win32\ppc386.exe
Duration: 00:00:00.610
Duration: 00:00:02.172

X:\freepascal\projects\processtest>processtest
\freepascal\fpc\trunk\bin\i386-win32\ppc386.exe
Duration: 00:00:00.484
Duration: 00:00:02.641

i'm at a loss for the difference in times for each of these as well as the much longer times in lazarus project->options->other :?

ROTFLMAO!!! i love it! :)

Sorry, I could not resist writing this... You may have other reasons for using Windows of course. :)

no problem, my friend... none at all... i do use linux on other boxen for mission critical stuffs... and i also have a few "primaries" running OS/2 eCS as well... but for everything i do, winwhatever currently takes all for the simple ease of use and i can do anything i want in 99% of the cases... since it is w2k, i am not restricted from being able to run DOS apps whenever i want... quite unlike the new winwhatever stuff out there today... habit and muscle memory are hard things to overcome when one is set in their ways with their daily tasks and goals ;)

Lukasz Sokol wrote

I for one would welcome having this info not as a 'message box' but rather as a status bar information (like ones you get on certain dynamic sites: this page was rendered in %d ms (options readout %d ms, render %d ms) ) (and an option to enable it or not, somewhere in Lazarus Tools).

The timings are now shown in a statusbar in the All options window. The compiler define is removed and the timings are shown to everybody. Please test.

Juha

One more thing about the timings:
The reading time includes 2 invocations of FPC, one for "fpc -i", another for "fpc -h".
It also includes the parsing but it is very fast.
My timings of < 50 ms means that one run of FPC takes < 25 ms.

Juha

The options are now read in a thread which is started when the "Other" page is opened.
It is not perfect still as sometimes the parsed data is not used, but who cares...
Please test.

Juha

this define? TimeAllCompilerOptions

i believe so and will remove it from my script for further testing...

question: with the timings in the status bar, can they easily be copied and pasted? previously i've had to waste a tree or two to retain them during a series of tests... but one tree isn't so bad i guess since i have 20 acres of them available 15 miles from anywhere ;)

waldo kitty wrote

this define? TimeAllCompilerOptions

Yes.

i believe so and will remove it from my script for further testing...

May I ask, why you need the script? I build Lazarus often but I don't need a script for it.

question: with the timings in the status bar, can they easily be copied and pasted? previously i've had to waste a tree or two to retain them during a series of tests... but one tree isn't so bad i guess since i have 20 acres of them available 15 miles from anywhere ;)

Based on Martin's comments I changed it to use DebugLn now. The StatusBar is gone.
It is easy to copy text from log / debug output.

Juha

On an atom based system linux gtk2, 2 runs:
RunTool /home/ludo/fpc_hg/trunk/bin/fpc.sh "-Tlinux" "-Pi386" "-i" RunTool /home/ludo/fpc_hg/trunk/bin/fpc.sh "-Tlinux" "-Pi386" "-h" AllCompilerOptions: Time for reading options: 00:00.726, rendering GUI: 00:01.762
AllCompilerOptions: Time for reading options: 00:00.726, rendering GUI: 00:01.705

Running from console while lazarus running (same memory conditions): $time /home/ludo/fpc_hg/trunk/bin/fpc.sh "-Tlinux" "-Pi386" "-i" real 0m0.012s
user 0m0.004s
sys 0m0.008s
$time /home/ludo/fpc_hg/trunk/bin/fpc.sh "-Tlinux" "-Pi386" "-h" real 0m0.038s
user 0m0.024s
sys 0m0.008s

So a lot of time is lost somewhere in reading the options. 50ms -> 726 ms. 1.7 secs to render a form is a lot. 300ms on an i7. But you indicated the form would use a faster grid in a the future:)

Ludo

Keep in mind that the first number may vary a lot, because it shows the time between start and end, not the time needed by the thread. In parallel the main thread paints the "other" options page, which has some impact on other processes.

"time" shows what the process alone needed - which is more accurate.

So a lot of time is lost somewhere in reading the options. 50ms -> 726 ms. 1.7 secs to render a form is a lot. 300ms on an i7. But you indicated the form would use a faster grid in a the future:)

Mattias

In that case, splitting the timing values between reading/rendering for single core cpu's (the atom is single core with hyper-threading) doesn't make sense. Rendering is very much cpu bound in this case.

On an i7 4 core I get Time for reading options 22ms for a total of 17ms on console. So that suggests indeed that on a single core, the rendering is the big problem.

Ludo

1 sec for rendering is not a big problem.
5 sec virus scanning is a big problem.

Mattias

Ludo Brands wrote

In that case, splitting the timing values between reading/rendering for single core cpu's (the atom is single core with hyper-threading) doesn't make sense. Rendering is very much cpu bound in this case.

Rendering the GUI must be done in the main thread anyways. Reading options from FPC does not happen at the same time with rendering the GUI. The options must be ready when the rendering starts.
The reading thread starts when a user selects the "Other" page. If the user clicks "All options" then the thread has most likely finished already, but there is a WaitFor in case it has not. The beauty of this is that reading the options happens while controls on "Other" page are drawn and while the user moves his mouse towards the "All options" button.

On an i7 4 core I get Time for reading options 22ms for a total of 17ms on console. So that suggests indeed that on a single core, the rendering is the big problem.

Yes, it is a problem. For some reason interaction with the widgetset and whatever takes lots of time.
I will work on other GUI after I collect some energy and motivation.

In my 233 MHz P2 machine the GUI took 9 seconds to render. Interestingly Lazarus is otherwise very usable there. I read comments on forum that Lazarus and especially GUI drawing is dead slow on Raspberry Pi although it has a faster CPU than my P2 has. It must be some display driver issue.
It takes 20 secs to start Lazarus in the P2 machine. It can be still optimized I believe.

Juha

Juha Manninen wrote

On Sun, Aug 25, 2013 at 4:04 AM, waldo kitty wrote: > this define? TimeAllCompilerOptions Yes.

thanks...

> i believe so and will remove it from my script for further testing... May I ask, why you need the script? I build Lazarus often but I don't need a script for it.

it is my update script... i update from FPC and LAZ trunk fairly regularly... i rarely (re)build LAZ from within LAZ... i'm not even sure i know how other than adding or removing packages... i've not tried anything more than that because i'm still (very slowly) trying to get a grip on the changes and differences from Borland's 6 and 7 stuff as well as still trying to wrap my head around GUI stuffings...

the basics of my update script are

1. check for and use (or not) miscellaneousoptions.xml if indicated on the script's command line. use existing if not specified.
2. make distclean (changed from plain 'clean')
3. TortoiseProc /command:update /path:"%myLAZpath%" (where myLAZpath is X:\freepascal\lazarus\trunk)
4. make OPT="-gl -gh -dHEAPTRC_WINDOW" lazbuild lcl basecomponents starter bigidecomponents lhelp
5. lazbuild.exe --build-ide="-gl -gh -dHEAPTRC_WINDOW" --build-mode="debug ide"

for both 4 and 5 i had added -dTimeAllCompilerOptions after -dHEAPTRC_WINDOW... as you can see above, it is removed now...

[aside] i just need to figure out where an extra set of "-gl -gh -dHEAPTRC_WINDOW" is coming from... i think the config containing the build mode but i haven't had much time or real drive to search it out lately since it appears to work as desired... [/aside]

thank you again... i do remember seeing that posed :)