[Lazarus] Timing of all compiler options on slow machines
waldo kitty
wkitty42 at windstream.net
Tue Aug 20 21:23:54 CEST 2013
On 8/20/2013 09:13, Juha Manninen wrote:
> 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 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 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.
:) 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...
> 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.
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...
> 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" buttons at all. It 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.
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...
>
> 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?
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...
--
NOTE: No off-list assistance is given without prior approval.
Please keep mailing list traffic on the list unless
private contact is specifically requested and granted.
More information about the Lazarus
mailing list