[Lazarus] Timing of all compiler options on slow machines

[Juha Manninen]

On Sun, Aug 25, 2013 at 2:51 PM, Ludo Brands <ludo.brands at 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