Re: Reboot: Strategic goals for GNOME

[Philip Van Hoof <pvanhoof gnome org>]

On Fri, 2010-03-05 at 13:42 +0000, Alan Cox wrote:
> > 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.

Right

> 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.

Of course, Doing this in combination with compression of said data is a
very good way to reduce latency too.

"Reducing events in general" is perhaps what I should have written? :)

It's indeed better to ask once and receive 3 larger chunks compressed,
than 50 individual small questions, and each time wait for a small
answers.

Although serious web applications are good at this, I don't think it's
already at the point of being very easy for average developers.

This is where I think we might gain or already have an advantage.

(But, the web is catching up - of course)

> 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.

Yes

On a less related note, it's always nice when Arjan passes by and
reduces the startup time of your thumbnail service by two seconds ;-)

http://git.xfce.org/apps/tumbler/commit/?id=cfb3dd90f4e23d911c2d55853dcb5dc05ceb9516

Thanks Arjan!

> > 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 - 

Ok, I was referring more to client-service situations like HTTP or IMAP
on remote services with latencies that are much worse than local events.

Nonetheless, you're right about this (I'm not involved in this kind of
work, so I'm going to refrain from commenting much on this).

> which was ignored with horrible consequences that knocked GNOME
> performance way back,

DBus's latency is also a bit of a problem for us, sometimes :-\

> and again about gconf (go admire the stats on a nautilus startup) which
> still makes more round trips that a corporate sales executive.

Ryan Lortie is working on GSettings and DConf, which uses an mmap for
read access and DBus for writes. Writes will still suffer of course.

I think this is finally arriving in GLib now. I hope.

> > 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.

Yes :-\

> 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.

OK


Thanks for your very informative reply, Alan.



Cheers,

Philip

-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be