[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ggi-develop
Subject:    RE: ggiFlush
From:       "Dmitry Semenov" <hatter () chollian ! net>
Date:       1999-10-05 9:25:34
[Download RAW message or body]

Thanks
	I've used the times function insted. clock has different behavior. It gives
of using cpu time :). Sorry for make troubles to you. Everyone uses clock to
determinate time between two events under win32 and dos. A porting problem.
Best regards, Dmitry

-----Original Message-----
From: becka@rz.uni-duesseldorf.de [mailto:becka@rz.uni-duesseldorf.de]
Sent: Monday, October 04, 1999 10:02 PM
To: ggi-develop@eskimo.com
Subject: Re: ggiFlush



Hi !

> I am sorry to make troubles to you with my carzy outlook software. Is this
> message ok?

Perfectly nice. Thanks !

> About my question. Look at my code attentivily. That piece of shit has to
> run not more not less than 10 sec. It should nod deppend on the target.
What
> is strange that function clock returned wrong result depending on GGI
mode.

Oops - that is weird. I admit I hadn't looked closely enough at your code.
Just saw some timing loop and thought it would be a run-this-x-times-and-
measure-the-time type speed check.

Sorry, I have already deleted your mail form the incoming folder, so I can't
look at it in detail anymore, but I can try to give a few possible
explanations. I suppose you do a
run-this-for-xx-seconds-and-count-how-often-
you-get-it-done type check - right ?

a) For X in sync mode, we are heavily messing with strange stuff like
sending
signals to the main process from a helper child to allow for the
asynchronous
(with respect to program execution) redraws.
However this should not interfere with the clock() function. It does
interfere
with sleep() and friends, however.

b) For X in ASYNC mode this cannot be the cause. If we don't have an array
overflow or something, I suspect it is c).

c) from man clock: clock() returns the amount of ***CPU time*** ...
   The time reported is the sum of the user and system times of the
   calling process ...

In X, we have a client-server model. That means you do not get the whole CPU
for your program anymore, as the X server has to do the actual drawing.
That will account for _the_X_Server's_ CPU time.

Thus it is possible for the loop to take >10 seconds of _real_ time,
while the process only has the CPU for 10 seconds of that time.

Letting top i run in a second xterm should allow to check that theory.

It should show about 50-70% CPU for the X server and the rest for your
program (and a bit for top and other stuff of course).

CU, ANdy

--
Andreas Beck              |  Email :  <Andreas.Beck@ggi-project.org>

[prev in list] [next in list] [prev in thread] [next in thread]