Many minor issues make a big issue

All of you who follow my blog for a medium to long time knows that I often take a look to minor issues. These are issues that have no direct impact on users. Summing them up, though, can easily give you big issues that do have a direct impact on users.

Take my crusade about copy-on-write pages. They don’t really make any difference taken one by one, but sum them up in a system, and it might as well make a huge difference.

It’s similar to the issue with wakeups that Intel brought on the table. It does not make much difference on its own for a single software, but add all of them together and you have a huge difference.

I wonder if we’ll ever get to a point where all these issues are well known by all the free software developers, and that just the new started projects need to be profiled to identify these issues. Unfortunately, I’m afraid this is not going to happen anytime soon. But it would be really interesting if common projects like Samba and Xorg started paying more attention to those issues.

I wonder what’s the best option to improve the situation. I actually thought about starting a Wiki listing all the problems if the apps, and then attaching patches for possible resolutions. I would hate to load a Wiki up on my blog though. As an option, I was thinking about using GIT and Emacs’s Muse, rebuilding the pages statically after every commit. Then it would also be possible to add stuff like graphs and similar to show the reduction in memory usage, or startup time, or whatever, which would then allow showing more easily what the changes improved.

I think solar was right in suggesting me to have more visual output of the changes. I’ve installed R yesterday, and I hope to be able to try learning how to use it soon, so that I can propose some graphs.

Anyway, any comment on this is very welcome, as I start to be quite tired to fight these issues alone, and having almost no feedback from upstream.

Exit mobile version