One of the main criticisms I hear about OpenBSD is that it's performance isn't as good as Linux. I've looked at a couple articles quoting benchmark comparisons, so I'll assume for the sake of argument that it's true.
The thing is that I don't care. I'm still an OpenBSD advocate and run it whenever I get the chance. I don't actually care about performance at that level. What matters more to me is consistency, and good man pages.
I imagine more people are like me, but the thing about performance measurements is they're quantifiable. They can be easily measured. We all probably over optimize to some degree, whether we're C developers or not.
There's just something satisfying about getting a quantifiably better score. This is why we get code that sacrifices almost everything for runtime speed.
The slowness isn't a generally impacted much by stuff like this. It's more things like OpenBSD's poor multicore performance that are the issue. Just compare the performance of FreeBSD's multithreaded PF to OpenBSD's singlethreaded PF. Still, none of this matters, because there's one major guarantee that the OpenBSD devs try to fulfil: correctness.
I suppose there are probably large groups of people who care about multicore performance on the metal, but my dominant use case is herds of single core VMs, each doing one thing (well!). In this case, host CPU and memory consumption matter, and OpenBSD is very hard to beat in this metric. My OpenBSD VMs normally consume 1/4 of the CPU time and run happily in half the RAM as my FreeBSD, Linux and Windows VMs. I don't know if there is a significant performance difference on a single CPU, but I certainly don't have any complaints about performance.
The thing is, the "slowness" in question is different every time someone wants to talk about it. Because people don't benchmark it, don't actually know what is slower and by how much, and just go on the "common knowledge" that openbsd is slow. The openbsd is slow meme was going strong in the 1990s, when it didn't support SMP at all and 99% of the people talking about it were using a single CPU.
It's different because the slowness is across the board.
FreeBSD and, especially, Linux have optimizations all over the place. A call to time(2) or gettimeofday(2) is hundreds of times faster in Linux than on OpenBSD. In most scenarios the difference doesn't matter. But it does matter in, e.g., an asynchronous network service with lots of events with timeouts being constantly registered.
I prefer OpenBSD, and I like that they focus on correctness, bugs, and more high-level features. I run all my personal services on OpenBSD. But commercially and at scale I run Linux, and treat each box as a throw-away in terms of security.
How does that make it not a bug? They've repeatedly responded to the "openbsd is slow" meme by pointing out that they do not have the time to benchmark anything, and if people do find slow things they should submit bug reports so they can be fixed. Nobody has ever submitted such a bug report.
I mentioned it on the mailing-list a long time ago, when I was more naive about these things. They said I should submit a patch. However, adding virtual syscalls is a non-trivial undertaking, and I'm not experienced enough with kernel internals, which will require wide-ranging changes, including adding special mapping support, hacking the program loader, and tweaking the clock subsystem.
Plus you also have to hack userspace. Most importantly you need to add VDSO support to the linker. Refactoring time(2) would be easy, but for higher granularity clocks--gettimeofday(2) and clock_gettime(2)--you need to make careful use of RDTSC and similar instructions for each architecture. _And_ you need to be able to test it well because of synchronization issues on older platforms. On x86, for example, RDTSC is synchronized, but for a long time it varied across cores, and when Intel and AMD fixed that there was a still a small product window where it could vary across CPU packages.
And the part where the developers explicitly say being slower than necessary is a bug and should be reported as such means it is a bug. This honestly is not complicated.
The thing is that I don't care. I'm still an OpenBSD advocate and run it whenever I get the chance. I don't actually care about performance at that level. What matters more to me is consistency, and good man pages.
I imagine more people are like me, but the thing about performance measurements is they're quantifiable. They can be easily measured. We all probably over optimize to some degree, whether we're C developers or not.
There's just something satisfying about getting a quantifiably better score. This is why we get code that sacrifices almost everything for runtime speed.