I don't have an immediate factual retort, but I personally have never experienced any performance issues. Do you have some form of benchmark or evidence you'd want to see on Plan9's performance?
Every year at the Plan9 International Workshop, we tussle with how to improve networking performance, particularly for streaming. Every 9p request needs to be rec'd. There's no look ahead. This makes it particularly unsuitable for streaming, for instance.
We have tried queued 9p responses, multiple 9p packets in the same tcp packet, extensions to the protocol. Nothing seems satisfactory enough to make it into the core.
Given the need to retrofit X11 with various mechanisms for fast local access to framebuffer or graphics accelerator, I have never been convinced that the 8 1/2 and Rio window systems, in which all drawing happened through streams of bytes, were complete and future-ready graphics systems.
I wonder if the "everything is a file" principle is actually Plan 9's weakness, a simplistic oversimplification of the nature of OS resources. What if we keep Plan 9's structure/topology (private namespaces, network transparency where possible) but redesign the fundamental file abstraction. Maybe this needs to happen at the level of a new instruction set which provides primitive data block transfer operations which can be implemented efficiently e.g. by memory mapping or dma on local hardware and which automatically fallback to streaming in the network case. Not new silicon but a fast virtual machine which provides network transparency and high performance where possible.
One thing to remember is that Plan9 was born as a research project. Another is that we don't consider it a jack-of-all-trades OS. It was built by programmers to facilitate their daily work. Importing namespaces is an amazing abstraction. You can do some truly wonderous things.
I was mainly curious about the performance hit of drawing operations. But your subjective assessment is enough to understand that the penalty is lower than I expected.
A lot of drawing on linux already goes over a "file", a PF_UNIX socket from the application to the X server - with the added penalty of making an additional round trip to the kernel, whilst on Plan 9 you just go directly to the kernel(as long as the application and display is running locally)
How does that work? Does Plan 9 run the display in the kernel?
Also communication with the X server can use shared memory - AIUI the modern GUI toolkits render everything to buffers themselves rather than using X drawing protocol calls, so I suspect drawing on modern linux is mostly a shared-memory thing.
Yes, it runs in the kernel on Plan 9. And sure, these days there's various optimzation using shared memory for a lot of the gfx or going via OpenGL when using X11.
I'm just saying unixes have done it a similar way to Plan 9 since almost forever - and it's not that big of a deal.
I can try to run some form of rudimentary benchmark tomorrow and I'll try to get back to this thread if I can.
As for drawing. Plan9 is intended to be used graphically. Although the interface is by majority text (which is very handy). Images and window usage in general is as run of the mill as would be expected in a graphical environment.
