
Why is printing “B” dramatically slower than printing “#”? (2014) - retox
http://stackoverflow.com/questions/21947452/why-is-printing-b-dramatically-slower-than-printing?noredirect=1&lq=1
======
nsxwolf
Best comment:

"The real answer is clearly because hashes are faster than b trees."

------
retro64
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.

------
anjc
I love it when somebody immediately knows the answer to something seemingly
obscure.

~~~
xeniak
Sometimes I think these guys know something obscure, and then post a question
about it just to answer it themselves.

SO actually allows this, Q and A from the same account. Some people use sock-
puppets though.

~~~
mark-r
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.

~~~
nucleardog
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.

------
atdt
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](https://bugzilla.mozilla.org/show_bug.cgi?id=1296050)
for the gory details.

------
rwmj
My guess was going to be Unicode, the reason why 'sort' on Linux can be so
slow if you're in certain locales.

[https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/846...](https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/846628)

------
stygiansonic
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.

0\.
[http://www.joelonsoftware.com/articles/fog0000000319.html](http://www.joelonsoftware.com/articles/fog0000000319.html)

~~~
heywire
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).

~~~
mjevans
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.

------
nkrisc
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.

------
JohnStrange
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.

I don't know how it works but it's insanely fast.

~~~
Lanzaa
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.

You might like to read the rationale section of PEP 471:
[https://www.python.org/dev/peps/pep-0471/](https://www.python.org/dev/peps/pep-0471/)

------
agumonkey
So printing B isn't slower: terminal rendering of lines of text is just less
obvious than thought.

~~~
__jal
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.

~~~
aidenn0
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.

------
pedrow
For what it's worth, the difference still exists when printing with Netbeans
8.1 - 41 seconds for 'B' and 2 seconds for '#'

~~~
marxidad
That also has to do with line-wrapping of word characters.

------
acqq
A lot of comments previously on HN here:

[https://news.ycombinator.com/item?id=7294186](https://news.ycombinator.com/item?id=7294186)

------
giomasce
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.

~~~
bjterry
According to my understanding, the rendered character is cached by the OS, so
this probably shouldn't have any effect.

------
Myrmornis
A good first step for investigating this would have been to redirect output to
a file.

------
baristaGeek
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.

~~~
Sanddancer
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.

------
macromaniac
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.

------
UlyssesSKrunk
Because # is only straight lines, but for b you gotta do the whole bezier
curve to make it look right.

