
Why is printing “B” dramatically slower than printing “#”? - marcopolis
http://stackoverflow.com/questions/21947452/why-is-printing-b-dramatically-slower-than-printing
======
codereflection
This post highlights the issue with overly zealous mods on SO who marked the
question as off topic. Nothing about this is off topic, and it turned out to
be very interesting answer.

~~~
gortok
The post was put on hold because the OP failed to provide the information the
community would need to reproduce the issue. What good is a programming
problem if no one else can reproduce it?

To have it reopened, all the OP needs to do is give the community all the
information they need to reproduce the issue. Should we ask any less?

It's also worth noting that the question was not closed by moderators (denoted
by diamonds next to their name), but by members of the community with high
reputation (> 3000). These users have community moderation powers by virtue of
their reputation, but are not moderators per se.

If you have over 3000 reputation, you could vote to reopen.

Full disclosure: I am an elected moderator for Stack Overflow:
http:stackoverflow.com/users/16587/george-stocker

~~~
overgard
A) The community did find the answer, regardless.

B) Someone is gifting free interesting content to the site; even if it's
imperfect does the reaction have to be so harsh? This is, personally, exactly
why I never post on stack overflow. You're acting like you're doing them a
favor by letting them post there, when they're doing you a favor by giving you
interesting content in the first place.

~~~
insteadof
The community, not moderators, closed the question. The community also had an
answer based on "Pure speculation" which means they can't replicate what the
OP asked.

A user can gift all the free interesting content they want. But if it's not
scoped or on topic, then it's not scoped for the site or on topic and would be
closed and/or deleted. Just because Rodney Dangerfield turns up to your
bedroom and starts making jokes doesn't mean it's the time or place.

~~~
sanderjd
Your analogy is bad because it would be very hard to ignore Rodney Dangerfield
in your bedroom, but it is very easy to ignore these sorts of questions. At
worst it sits there and nobody comes up with an answer. We aren't running out
of bits.

~~~
MaulingMonkey
It's easy to ignore singular questions like this. It's harder to ignore such
questions when they compose 99% of the content source you're interested in,
without ignoring the entire source - including the 1% of signal you care
about. We _are_ certainly running out of mental bandwidth all the time, even
if you aren't counting them as bits.

This sort of community moderation exists in an attempt to proactively ensure a
high signal to noise ratio (SNR), by discouraging noise. While it's an
entirely valid stance to say they're overreacting and that the ratio is fine,
that there's no slippery slope, etc., here's another viewpoint:

I don't read from the raw Stack Overflow firehose of posts. It doesn't even
have a 1% SNR to me. Higher SNR sources (searches, specific links from my
communities) will occasionally take me there, but as a primary source of
information I don't even think of consulting it. I took a stab at
participating in one of the far more niche subtopics - gamedev, relevant to me
both professionally and unprofessionally - and still found it didn't have a
high enough SNR to hold my interest beyond gathering a few hundred internet
points. I found myself ignoring the majority of these sorts of questions, and
quickly progressed to the natural conclusion of ignoring the site entirely.

And that's fine: Not everything is for everyone. But there are presumably
those who still participate in the site directly who would prefer to remain
doing so, yet find the SNR low enough to be pushing their own tolerances.

~~~
sanderjd
Thanks, this is a great response. I see the problem now. The SNR is plenty
high enough for my use case of searching for content and following links, but
to ensure that a high number of the links that I follow have good answers,
it's important to keep the SNR reasonably high for those who are looking
through the firehose for things to answer. Makes sense.

------
koenigdavidmj
Entirely unrelated, but this headline made me notice that Chrome finally
supports entering " in the find-in-page box and having it match so-called
smart quotes.

~~~
w1ntermute
Meanwhile, Firefox continues to distinguish between e and é when searching,
despite Chrome having fixed this bug years ago.

~~~
reubenmorais
> this bug

"9001 Wrong Things Programmers Assume About Internationalization"

This behavior should at a minimum be locale-aware. I would be surprised if
Firefox did that by default in my pt-BR profile.

~~~
chavesn
(I'm not programming this kind of thing so please forgive my ignorance.)

Is that loose of a search not actually desirable in "find in page" instances?

In other words, are there many words where 'e' matching 'é' would actually
generate a false positive? This is the only case I could see that would be
problematic.

And even then "find in page" is usually used as quick navigation to the
minimum matching search (high recall) and not about excluding all possible
mismatches (high precision).

~~~
logicchains
There are words in other languages, French for instance, that with an accent
changed or removed have completely different meaning.

~~~
bausson
That is sadly true.

It's even worse than that. 'e' is the most used letter in french, but 'é' and
'è' are quite used too. 'ê' and 'ë' being rarer, but still existing.

So, I am exaggerating it a bit, but you can compare it to having to search for
words with the consonants, because every vowel is considered the same by your
search algorithm.

Yes, I'm pushing it, but you see the problem it can easily become in huge
pages.

~~~
JetSpiegel
Why sadly?

~~~
bausson
What is sad for me is chrome new way of handling thing, not french accents
(which can be a bother, but they're cute, so that's ok).

Most pages nowadays are small enough that it won't be a bother, but their
still are some cases (newspaper posts, blog analysis, etc...) where accent
sensitiveness will be an issue.

------
cbsmith
Oh good lord. This question is more about properly isolating your tests (i.e.
writing the characters to /dev/null and getting rid of the "random" call) and
properly profiling code (which would show high CPU consumption on the
_console_ , not the program writing to stdout) more than anything "tricky"
about performance.

~~~
yeukhon
The problem is, who on earth would have thought of printing to terminal would
have a big penalty?

~~~
vehementi
I've run into it before... I've had compiling etc. limited by the speed & size
of my console window.

Isn't it common knowledge though? Cat some 1GB file to your terminal and
notice it takes more than the <100ms it takes to cat it to /dev/null.

~~~
cabinpark
Never assume something is common knowledge! I've seen many links to
mathematics things here on HN that I would consider "common knowledge" yet
many people were unaware of them.

------
gavinpc
Hilarious! I never see confirmation bias in action so much as when SO answers
get posted on HN:

"See, this is exactly what's wrong with SO."

"Really? Because it seems like a perfect example of why SO works perfectly."

Of course, I find I am increasingly disposed to read the comments that way...

------
chris_wot
Just shows that seemingly obscure questions can often show that there are
underlying things you need to pay attention to!

------
jrockway
This, incidentally, is a good user interface study. The terminal emulator
works so well that most users don't even know it's there. But it's actually a
pretty complex piece of software.

------
tedchs
Apparently the answer had to do with terminal word-wrapping. A good test would
be to write the output to a file instead of the terminal and compare the
difference in timing.

~~~
VLM
A graph of wall clock printing speed vs line length for each character would
have been highly enlightening. Of course we'd hope anyone who did that would
figure it out themselves without posting the question.

If it wasn't a line length issue, it probably would have been

1) Proportional kern'd antialiased fonts some glyphs hardware accelerated some
not.

2) Maybe for speed it only caches certain font glyphs but its an anti-
accelerant strategy this time. After all, what normal person generates outputs
like this?

3) UTF-8 to ASCII and or localization code gone wild or similar
misoptimization.

4) You'd like to think a simple string printer and the fancy formatted string
printer (aka printf and friends) are separate optimized routines but the
simple printer might actually be a degenerate form of the formatted printer
and the formatted printer has a severe hangup about certain characters. Maybe
# is processed quickly but b gets processed extremely slowly because its
regex'ing in a very inefficient way to find the \ as in \b.

5) remember LTRS/FIGS from baudot 5 bit teletype coding? Someone trying
something "funny" with 3-d accelerated text rendering treating certain letters
as 3-d sprites and some not and its getting all messed up and unoptimized this
time. Someones LRU cache of 3-d glyph/sprites isn't as LRU as you'd like to
think, perhaps.

------
Ellipsis753
I find it amazing that they actually got the correct answer. How on earth did
they guess that?

~~~
jodrellblank
The guesser comments that they have written word-wrap code before many times,
and recognised the problem from experience.

~~~
akx
Which reaffirms what I've been saying for a while: Plenty of programming
prowess is creative pattern matching.

------
ansible
There are terminals that do word wrapping?

Well, I shouldn't be surprised... There are people who try to code with a
proportional font too, so I guess anything is possible, though it may not make
sense to me.

~~~
nolok
The output console in many IDE in default configuration, the output console in
many linux distros visual updater/installer (eg in xubuntu and mint), etc ...

Terminal is a very large word these days. In the SO post, he was using the
output console of NetBeans.

------
prewett
I'm actually a little surprised that the answer wasn't something along the
lines of "# is simple straight lines, while B requires a bunch of Bezier
splines for TrueType to render." I guess the graphics cards must accelerate
that or something. I'm surprised that line-breaking algorithms take that long.

~~~
agumonkey
About that, I wonder how common are path rendering extensions used ( like
NV_PATH [http://zrusin.blogspot.fr/2011/09/nv-path-
rendering.html](http://zrusin.blogspot.fr/2011/09/nv-path-rendering.html) ).
I'd be sad to hear that my cpu is wasting time on font rendering in 2014.

------
delinka
1) Asking about running times on code with calls to an RNG ... remove the
randomness first, profile repeatedly

2) Outputting to STDOUT can have some serious overhead depending on where
you're actually rendering the text-- textview inside your IDE? Crazy, off-the-
wall terminals? Let's dump this to a file and see how long it takes

------
est
reminds me of worldwide newbie python Unicode rage. The culprit was Windows's
cmd.exe and Linux's LC_ALL

------
fexl
I bet if he had redirected the output to /dev/null it wouldn't be slower with
'B'.

------
chj
good detective work!

------
muro
Printing random boobs is slow, okay.

~~~
muro
did you folks read the code?

