This reminds me of a bug I had back in ‘98 or so. I was using a Parallax BASIC stamp and could not understand why when I put it to sleep it would sometimes using only 30 uA, and other times 300uA. I kept narrowing down my code until it was utter nonsense, and finally I made it to where if I removed or added a byte of code it would toggle between the two.
I got on the phone with the engineer responsible for the firmware and sent him my code, but I never did find out what the problem was (sorry for the letdown, maybe someone at Parallax remembers and reads Hacker News?). They acknowledged it as a bug, and made a fix. Unfortunately the fix made was to always draw 300uA at sleep!
Fast forward 18 years (!) and from their website it looks like their latest modal draws 50uA, so it was a happy ending after all. The end.
I've done the self-answer thing a couple of times. Sometimes you just know that someone is going to run into the same problem, but you'll never see the question, and you can preempt it.
I think I've posted on StackOverflow/ServerFault three times in my life. If I've hit the point where I'm posting, I'm desperate and I've probably already spent 8+ hours scouring Google and trying everything I can think of.
If I do end up figuring out a solution, I definitely post it, and I'm glad that SO allows this, otherwise there would still be no answer to some of these questions online... One of these issues previously only turned up a single bash mailing list post from a decade ago with no resolution. Now searching for a few relevant search terms turns up my answer/solution in the top few results for all of them.
I don't care about imaginary internet points, I just figured I'd help the next guy out.
More than once I've solved the problem by the time I am 80% of the way through formulating a question. As long as it's not something trivial I finish and post the answer immediately.
People use sock puppets to do this because although you're correct that it's with the SO guidelines, it feels a bit off, and not uncommon for it to get pushback from those who either don't agree with the guidelines or are not aware of them.
Also, while voting fraud is against the guidelines and actively countered, creating sock puppet accounts is not.
Sometimes the act of writing out a question is enough to spur the right ideas to solve the problem. It's the same as whiteboarding or asking to use someone as a sounding board.
> There are some answers that come from hard learned experience. T.J. and I (since we are friends) grew up in the days of the Apple ][ and the zx80/81. There was no built in word wrap back then. So we both ended up writing our own — more than once. And those lessons stick with you, they get burned in to your lizard brain. But if you leaned to code after that, when your environment word wraps everything, or you do it manually prior to runtime, it is harder to run into the issues with word wrap. – JockM
I am amused when someone comes up with obscure problems. I am disappointed when that person doesn't brief about the scenario that led them to such a problem.
The 10X immediately knows the answer. The 100X immediately knows the answer, but asks "That is an interesting observation and I'd really like to know why too. But is writing 1 million characters to the console essential to the problem your solving?"
"You are confused because you do not understand Tao. Only a fool expects rational behavior from his fellow humans. Why do you expect it from a machine that humans have constructed? Computers simulate determinism; only Tao is perfect.
The rules of programming are transitory; only Tao is eternal. Therefore, you must contemplate Tao before you receive Enlightenment."
"But how will I know when I have received Enlightenment?" asks the 100x engineer.
"Your program will run correctly," replies the 1000x engineer.
Meanwhile, the 10kx engineer sits here on HN, doing nothing while requirements change again and again - waiting to implement the thing when the requirements finally settle.
It's really an example that we should teach people to use a sampling profiler. anyone can answer this question in a minute or so, no speculation necessary, if they just know what tool to use.
Except the insight of the answer is that the bottleneck is in a different program than suspected. Running the suspect program under a profiler wouldn't yield any answers.
Sure, anyone can find the answer if they already know where to look.
Running the suspect program would show blocked states; even without that, you would simply see no difference, conclude that the problem must lie elsewhere, and switch to looking at a full system profile.
FWIW, I always start with a full system profile including all thread states when debugging mysterious performance issues, precisely because "the problem is in another process" is such a common occurrence. This is also why it's important to use a sampling profiler specifically.
Heh, reminds me of a bug I ran into a couple of weeks ago. Users on Wikipedia were complaining that typing into the editor <textarea> on certain pages was sluggish. I eventually narrowed it down to the presence or absence of an invisible left-to-right or right-to-left mark control characters elsewhere in the page. See https://bugzilla.mozilla.org/show_bug.cgi?id=1296050 for the gory details.
So, in effect, with word-wrapping on in the terminal, this scenario effectively produces a "Shlemiel the painter's algorithm" [0] in that for every character output on the same line (when it exceeds the line length), you have go backtracking in vain to find a place to break - where this is none - so outputting N characters on a line is basically an O(N^2) operation.
I wonder if this is also why the default terminal in Ubuntu slows to a crawl if you write a ~4kb long line (I was working on a program which was processing some SDR data, outputting 0/1 to the screen without any line breaks).
Probably that or some other case of selecting an algorithm without consideration of the /worst possible/ performance cases.
It may be better to try a generally good algorithm first, then if it fails after X iterations to fall back to an algorithm with a better bound on the worst case.
Maybe it's just not reflected in the question, but did the asker not immediately try other characters to see if there's a pattern? Given the answer, other letters would probably have had the same result and other characters would not. They could have at least narrowed the problem down to letters.
While we're talking about obscure speed differences, I recently needed to traverse large directories and collect files with a certain suffix and found out that using "find" as a subprocess and parsing its output line-by-line was orders of magnitudes faster than any direct directory traversal I wrote and any other method I've tried, including other Unix utilities.
The find utility is probably smarter than the other methods. I know two things to watch out for: sorting the directory entries and calling stat on each entry.
Any time I'm seeing really strange results involving the terminal, I try to look for terminal-related weirdness. There is a lot of stuff going on that people generally ignore or simply don't know about, because it generally just works.
And when it doesn't, if you're not at least a little familiar with what's going on, it can be a deeply confusing and obscure little world.
I don't know if it's still valid, but SBCL has a readme entry indicating that building in xterm is much faster than building in gnome-terminal. SBCL's build output is incredibly noisy and the compiler is quite fast, so the combination of the two makes for an incredible rater of output to the terminal.
I remember how confusing IO was in college. Even the implicit flush requirement to show stuff. Utter dread. Few years ago I read an old lisp book (something written before Common Lisp), they don't touch IO until the end, for transparency/bootstraping reasons, and since it's insignificant for thinking it's a straightforward model without fancy features, I wish people taught CS this way.
My first guess was that for most fonts the glyph "B" has splines, while "#" does not (only segments) and in line of principle rendering splines is more expensive than rendering segments. But probably this is nowhere that relevant.
That was my first thought too, but I expect glyphs will probably be cached for a while after being rendered, which should make any difference in rendering speed negligible.
Let's talk about any potential application this could have.
The first thing I can think of is that if you're writing a flood-filling algorithm (finding connected components) you should fill with #s instaed of Bs, even if filling with Bs is more conventional. Specially if you're doing competitive programming and need to overkill the optimization process in order to pass the run time.
As for production coding, I can't think of anything. Any ideas?
BTW, this is probably speculation, but it's still worth discussing in my humble opinion.
Things like printing out progress bars for long operations stand out here. Lots of programs have an option to do such as a quick and dirty way to give feedback.
While stuck at a meeting today I learned you can type faster than notepad can render by making the text really big. (AltSpace X, Alt O, F, S, 600, Enter, spam buttons) The text lags just slow enough so you can use it as a ghetto marquee.
"The real answer is clearly because hashes are faster than b trees."