Ça commence doucement à me saouler d'entendre dire partout que X est lent à cause de la couche réseau. Ce mythe a la vie dure.
Pour ceux qui y croyaient encore, je rappelle qu'en local, X utilise les sockets Unix et la SHM, ce qui est la combinaison la plus rapide pour faire des IPC sous Linux (je ne m'avancerai pas pour les autres OS).
Ce qui pose problème, c'est l'implémentation actuelle de la Xlib et les applis. Le protocole X est asynchrone alors que la Xlib ne l'est pas toujours.
Si je me souviens bien, j'avais lu quelque part qu'un remplaçant en Lisp était en cours ou a l'étude, pour justement ne plus perdre ce mode asynchrone entre les applications et le serveur X.
De plus, il existe aussi au moins un "proxy" X qui fait de la compression/optimisation du protocole X pour accélérer tout ça : NX de Nomachine (http://www.nomachine.com(...) mais le site ne répond pas au moment où j'écris).
Bon, après mon coup de gueule, je vais quand même lire le pdf :)
# Re: Après X, voici Y...
Posté par Amand Tihon (site web personnel) . En réponse à la dépêche Après X, voici Y.... Évalué à 10.
Pour ceux qui y croyaient encore, je rappelle qu'en local, X utilise les sockets Unix et la SHM, ce qui est la combinaison la plus rapide pour faire des IPC sous Linux (je ne m'avancerai pas pour les autres OS).
Ce qui pose problème, c'est l'implémentation actuelle de la Xlib et les applis. Le protocole X est asynchrone alors que la Xlib ne l'est pas toujours.
Si je me souviens bien, j'avais lu quelque part qu'un remplaçant en Lisp était en cours ou a l'étude, pour justement ne plus perdre ce mode asynchrone entre les applications et le serveur X.
De plus, il existe aussi au moins un "proxy" X qui fait de la compression/optimisation du protocole X pour accélérer tout ça : NX de Nomachine (http://www.nomachine.com(...) mais le site ne répond pas au moment où j'écris).
Bon, après mon coup de gueule, je vais quand même lire le pdf :)