Re: Reboot: Strategic goals for GNOME

[Alan Cox <alan lxorguk ukuu org uk>]

> In my opinion you solve latency more by making services capable of
> pipelining, than by compressing data. And by making clients that make
> use of the remote service's pipelining capabilities.

Thats a bit naïve. They two solve totally different problems and it is
dependant upon the behaviour of the pipe which matters. Compression
reduces latency by lowering time from initiation of transmit to
completion of receive. Pipelining removes some of the other overheads but
only if causality permits it, which can often be a big problem.

Now if you do look at serious mobile and web applications its not
pipelining thats a key part of the design at all. It's understanding
the transaction seequences, making bandwidth/latency tradeoffs and being
able to figure them out on the fly.

As bandwidth rises over latency you start to answer questions that are
not asked - just in case. So for a typical "3G" phone user you get some
benefit from dumping chunks of info to the client to avoid round trips.
Serious developers of these tools can actually show you the graphs of
each transaction, and the decision trees for different transaction
patterns that have been carefully plotted out to minimise the number of
events. I've seen some of that with low level X toolkits, and nothing
much with the GNOME desktop. Its taking people like Arjan and the Moblin
startup work to turn up all the real uglies and dubmness in the desktop.

> UI and client developers should learn to build state machines instead of
> threads that work like (where [...] is ~ an IP frame):

Doesn't need to be a state machine, you just need enough parallelism to
fill the pipe. Exceeding that can actually reduce performance for other
reasons.

But yes I think this is what the low level graphics people have been
trying to tell the desktop people for years and where some work on the
UI toolkits happened. It's what the kernel people have been trying to tell
the Gnome people for years about disk I/O patterns, its what the component
people tried to tell everyone years ago about Bonobo - which was ignored
with horrible consequences that knocked GNOME performance way back, and
again about gconf (go admire the stats on a nautilus startup) which still
makes more round trips that a corporate sales executive.

> This, however, isn't always simple with the newest "HTML5 + Javascript"
> technologies. Meaning that GNOME's desktop technologies has an advantage
> here.

I don't see that as being the case. GNOME has a lot of horribly latency
inducing code in it much of which needs a serious effort to get back out.
It was designed for a different world.

I think the advantage is actually with the opposition. They have designed
from day one for latency, they have avoided inheriting dumb latency heavy
models and they don't have the compatibility legacy that GNOME has to
worry about in solving them.


Alan