Slashdot Mirror
Performance Bugs, 'the Dark Matter of Programming Bugs', Are Out There Lurking and Unseen (forwardscattering.org)
Several Slashdot readers have shared an article by programmer Nicholas Chapman, who talks about a class of bugs that he calls "performance bugs". From the article: A performance bug is when the code computes the correct result, but runs slower than it should due to a programming mistake. The nefarious thing about performance bugs is that the user may never know they are there -- the program appears to work correctly, carrying out the correct operations, showing the right thing on the screen or printing the right text. It just does it a bit more slowly than it should have. It takes an experienced programmer, with a reasonably accurate mental model of the problem and the correct solution, to know how fast the operation should have been performed, and hence if the program is running slower than it should be. I started documenting a few of the performance bugs I came across a few months ago, for example (on some platforms) the insert method of std::map is roughly 7 times slower than it should be, std::map::count() is about twice as slow as it should be, std::map::find() is 15% slower than it should be, aligned malloc is a lot slower than it should be in VS2015.
In 1973 or 1974 I was the systems programming manager at the National Academy of Sciences after our IBM mainframe had been upgraded to the first version of the OS supporting virtual storage. And many programs, mostly Fortran programs, were running much slower than they used to. The problem was two-dimensional arrays and how they were initialized and searched. If you're looping through the wrong subscript in a big array, you cause a page fault every time you increment it. Flash storage makes that a much smaller problem than it is with disk drives, but I'm sure most programmers today have no idea that this problem exists or how to handle it.
And yet from an end-user point of view, Windows 8 and subsequent basically headed right back to Program Manager.
When I think back to my Windows 3.1 experience, I had a launcher in the form of Program Manager, a file tree browser called File Manager, I had the ability to run several programs at the same time, I had the ability to play video and sound including playing music from file and from CD, I could access network storage and map resources to use as if they were local, and I could even use a web browser to access the fledgling Internet. Hell, the local college was part of the Internet so I had 10BaseT connectivity to what was available at the time.
My point is that while the back-end of 16-bit Windows 3.1 is essentially gone, the way that people use Windows operating systems is substantially similar to the way it was almost 25 years ago. Obviously particulars have changed, but when you fundamentally look at the end-user experience versus the increase in hardware requirements and the sheer size of the install base you must wonder where all that effort really went, because from the end-user point of view it's not really all that obvious.
Do not look into laser with remaining eye.