Wayland performance

Also from the article, current (tho incomplete) wayland code is ~10KLines, xorg is half a million. Now surely the klines of wayland code will increase, but a lot of that xorg code is legacy stuff that (approximately) no one uses any more. So even allowing for a 10X increase in lines of code (the first 90% of the implementation's only 10% of the code, or 80/20, or whatever), wayland should still be far smaller, thus being far more memory efficient.

And even where memory isn't a problem on today's multi-gig-memory machines, smaller code means more of it fits in caches closer to the processor, where it's MANY times more efficient to access and thus faster running! =:^)

Of course, the biggest benefit there will only happen once most/all normally running apps are wayland, not X. But with a 50:1 or even if wayland's code grows by 10X, a 5:1 size difference, it won't take replacing /much/ of that legacy X code with wayland, to break-even and start the reduction, even while the majority of apps are still X. So we may begin to see memory benefits sooner than one might have expected, even while most apps remain X.

Not that this will be the major benefit, but it's one of them.

I think the biggest user visible improvement will likely be in stability, tho. There's a LOT of legacy code in X, and thus a lot of dingy corners for bugs to lurk in. Additionally, wayland is designed from the ground up to current kernel driver and mode-setting reality, while that functionality has sort of been bolted on to X. The more "direct drive" nature of wayland as well as the vastly smaller code should make tracing and eliminating bugs FAR easlier, at least for the first half-decade or so. After that, I guess we'll have to see, as X really HAS been great at adapting to the changes underneath and around it, and for any replacement to last as X has for over three decades and continue functioning as well as X still does today, despite all that legacy, is going to be quite a challenge indeed, to match!