[gDesklets] Reviewing desklets loading sequence

["Johan Euphrosine" <proppy aminche com>]

Hi,

I've been playing with gdesklets code, trying to accelerate the loading
of a profile with at least 6 desklets.

proppy nihiki:/usr/lib/gdesklets$ time gdesklets start
Connected to daemon in 399 milliseconds.
real 0m2.447s
user 0m0.100s
sys 0m0.020s

After applying the following tweaks to the timeout in RemoteServer.py:
http://pastebin.com/m75a53401

I got better result:

proppy nihiki:/usr/lib/gdesklets$ time gdesklets start
Connected to daemon in 306 ml 0m0.983s
user 0m0.104s
sys 0m0.024s

Is such tweaking of these timeouts recommended ?

Looking at the client - server interaction:

It seems that gdesklets client code for open_profile does the following:
for display in profile:
   send(open_display, display)
   recv() # block until open display response is received

I noticed that open_profile doesn't care of the response received.

Would it be possible to batch the request so that the client does not
wait for the server response before requesting to open the next display
of the profile ?

I tried to comment the recv() call in method __send but I don't feel
very comfortable with it, because other callers might actually be
interested by the server response :)

On the server side:

each 250ms:
    request = recv_non_blocking()
    if request
       response = handler(request)
       send(response)

client_handler is called each 250ms, and send the response after having
processed the handler of the request, which will cause the client to
blocks in the recv call (and not sending next request) while the handler
is processed.

Would it be possible for certain request type to determine and send the
response before calling the handler ?

If so, would it be possible to thread the handler execution, so that the
server could proceed the next request right away ?

Have you considered using twisted ( http://twistedmatrix.com/ ) +
gtk2.reactor for the server side ? Because twisted.defer.Deferred looks
a lot like the construct you used for __pipeline.

These are preliminary profiling results, I've generated using hotshot:

For client: http://pastebin.com/m53b8ec4c

Most of the time seems spent in xdr.py:67(recv), blocking until some
data are available to read from the socket.

And server: http://pastebin.com/m75f39dc7

Most of the time seems spent in gdesklets-daemon:96(_gdesklets_main),
waiting for gobject.timeout events to occur.

Hope that helps.

Thanks in advance.
--
Johan Euphrosine <proppy aminche com>