Re: [Lazarus] Timing of all compiler options on slow machines
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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On Sun, Aug 25, 2013 at 4:04 AM, waldo kitty wkitt...@windstream.net 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On 08/25/2013 10:24 AM, Juha Manninen wrote: On Sun, Aug 25, 2013 at 4:04 AM, waldo kitty wkitt...@windstream.net 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. 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 real0m0.012s user0m0.004s sys 0m0.008s $time /home/ludo/fpc_hg/trunk/bin/fpc.sh -Tlinux -Pi386 -h real0m0.038s user0m0.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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On Sun, 25 Aug 2013 12:06:31 +0200 Ludo Brands ludo.bra...@free.fr wrote: On 08/25/2013 10:24 AM, Juha Manninen wrote: On Sun, Aug 25, 2013 at 4:04 AM, waldo kitty wkitt...@windstream.net 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. 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 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. 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 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On 08/25/2013 01:00 PM, Mattias Gaertner wrote: On Sun, 25 Aug 2013 12:06:31 +0200 Ludo Brands ludo.bra...@free.fr wrote: 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 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. 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On Sun, 25 Aug 2013 13:51:03 +0200 Ludo Brands ludo.bra...@free.fr 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. 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. 1 sec for rendering is not a big problem. 5 sec virus scanning is a big problem. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On Sun, Aug 25, 2013 at 2:51 PM, Ludo Brands ludo.bra...@free.fr 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On Tue, Aug 20, 2013 at 7:11 PM, Lukasz Sokol el.es...@gmail.com 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On 8/24/2013 05:36, Juha Manninen wrote: On Tue, Aug 20, 2013 at 7:11 PM, Lukasz Sokolel.es...@gmail.com 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. 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 ;) -- 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On Thu, Aug 22, 2013 at 3:50 AM, waldo kitty wkitt...@windstream.net 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On 20/08/2013 14: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. 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On 8/22/2013 05:56, Juha Manninen wrote: On Thu, Aug 22, 2013 at 3:50 AM, waldo kittywkitt...@windstream.net 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. 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 ;) -- 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
Am 21.08.2013 17:45, schrieb Sven Barth:
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
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.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On 8/22/2013 06:58, Martin wrote: 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 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... -- 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On Thu, Aug 22, 2013 at 2:50 PM, waldo kitty wkitt...@windstream.net 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
Am 22.08.2013 14:14, schrieb Juha Manninen: On Thu, Aug 22, 2013 at 2:50 PM, waldo kitty wkitt...@windstream.net 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On 8/22/2013 07:42, Sven Barth wrote:
Am 21.08.2013 17:45, schrieb Sven Barth:
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.
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...
--
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.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
Am 22.08.2013 14:38, schrieb waldo kitty:
On 8/22/2013 07:42, Sven Barth wrote:
Am 21.08.2013 17:45, schrieb Sven Barth:
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.
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?
'Program' or 'Simple Program' would have been correct. Alternatively you
could have compiled it on the command line as well...
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'
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.
running gives me the following in a popup box...
Process processtest raised exception class 'RunError(103)'.
Maybe you should have chosen 'Program' indeed. ^^ Alternatively add
{$apptype console} at the top or disable GUI application in the
project options.
Regards,
Sven
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On 8/22/2013 07:42, Sven Barth wrote: 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. i went back and created a new project but chose 'Program' this time instead of 'Application' and that works much better... X:\freepascal\projects\processtestprocesstest Duration: 00:00:04.750 Duration: 00:00:02.421 X:\freepascal\projects\processtestprocesstest Duration: 00:00:01.047 Duration: 00:00:01.063 X:\freepascal\projects\processtestprocesstest Duration: 00:00:00.921 Duration: 00:00:01.047 X:\freepascal\projects\processtestprocesstest Duration: 00:00:01.188 Duration: 00:00:01.219 X:\freepascal\projects\processtestprocesstest Duration: 00:00:01.047 Duration: 00:00:01.047 X:\freepascal\projects\processtestprocesstest Duration: 00:00:00.813 Duration: 00:00:00.922 X:\freepascal\projects\processtestprocesstest Duration: 00:00:01.265 Duration: 00:00:01.281 X:\freepascal\projects\processtestprocesstest 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\processtestprocesstest \freepascal\fpc\trunk\bin\i386-win32\fpc.exe Duration: 00:00:01.094 Duration: 00:00:03.281 X:\freepascal\projects\processtestprocesstest \freepascal\fpc\trunk\bin\i386-win32\fpc.exe Duration: 00:00:01.031 Duration: 00:00:03.156 X:\freepascal\projects\processtestprocesstest \freepascal\fpc\trunk\bin\i386-win32\fpc.exe Duration: 00:00:01.157 Duration: 00:00:02.859 X:\freepascal\projects\processtestprocesstest \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\processtestprocesstest \freepascal\fpc\trunk\bin\i386-win32\ppc386.exe Duration: 00:00:00.500 Duration: 00:00:02.485 X:\freepascal\projects\processtestprocesstest \freepascal\fpc\trunk\bin\i386-win32\ppc386.exe Duration: 00:00:00.610 Duration: 00:00:02.515 X:\freepascal\projects\processtestprocesstest \freepascal\fpc\trunk\bin\i386-win32\ppc386.exe Duration: 00:00:00.610 Duration: 00:00:02.172 X:\freepascal\projects\processtestprocesstest \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 :? -- 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On 8/22/2013 08:14, Juha Manninen wrote: On Thu, Aug 22, 2013 at 2:50 PM, waldo kittywkitt...@windstream.net 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. 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 ;) -- 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines [OT]
On 20/08/13 20:23, waldo kitty wrote: On 8/20/2013 09:13, Juha Manninen wrote: [...] 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... 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 ;) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On Tue, Aug 20, 2013 at 10:23 PM, waldo kitty wkitt...@windstream.net wrote: 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 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On 8/21/2013 10:03, Juha Manninen wrote: On Tue, Aug 20, 2013 at 10:23 PM, waldo kittywkitt...@windstream.net wrote: 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 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. it is pretty standard for this old AMD 2800+ system... at least for now, anyway... 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 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 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. 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 ;) -- 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On 20.08.2013 21:23, waldo kitty wrote: 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... 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On 8/21/2013 11:45, Sven Barth wrote: On 20.08.2013 21:23, waldo kitty wrote: 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 [...] 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 ;) -- 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On 8/21/2013 12:48, waldo kitty wrote: On 8/21/2013 11:45, Sven Barth wrote: [...] 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 :? 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:\freepascaldir 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:376,628,352 fp.exe 06/02/2013 14:277,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:333,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:125,753,344 ppc386.exe 07/31/2013 12:35 43,520 ppdep.exe 07/31/2013 01:103,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:351,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:371,345 yylex.cod 06/02/2013 12:374,334 yyparse.cod 51 File(s) 25,484,858 bytes 2 Dir(s) 5,241,798,656 bytes free X:\freepascal -- 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Timing of all compiler options on slow machines
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 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. 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? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
Am 20.08.2013 15:14 schrieb Juha Manninen juha.mannine...@gmail.com: 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On Tue, 20 Aug 2013 16:58:21 +0300 Juha Manninen juha.mannine...@gmail.com wrote: 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On Tue, Aug 20, 2013 at 5:57 PM, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Tue, 20 Aug 2013 16:58:21 +0300 Juha Manninen juha.mannine...@gmail.com wrote: 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? 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On 20/08/13 14:13, Juha Manninen wrote: Attention waldo kitty and others with slow machines. [...] 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 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. [...] 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
On 20.08.2013 17:48, 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Timing of all compiler options on slow machines
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
