On 08/25/2013 01:00 PM, Mattias Gaertner wrote: > On Sun, 25 Aug 2013 12:06:31 +0200 > Ludo Brands <[email protected]> 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 [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
