> 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 _______________________________________________ foundation-list mailing list foundation-list@gnome.org http://mail.gnome.org/mailman/listinfo/foundation-list