Why is printing “B” dramatically slower than printing “#”?

http://stackoverflow.com/questions/21947452/why-is-printing-b-dramatically-slower-than-printing

by marcopolis • 12 years ago

260 115 12 years ago

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.

shurcooL• 12 years ago

I recall it doing that (for other symbols too) for quite a while. At least 4-6+ months, on stable channel.

oneeyedpigeon4• 12 years ago

Yup, it's definitely done that for a while. It does become a pain when you actually want to locate quotes that need smartening up, though.

GauntletWizard• 12 years ago

Why? Why would you do that to the world? Smart quotes are about the dumbest concept that has ever existed.

w1ntermute• 12 years ago

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

scott_karana• 12 years ago

Does it depend on the locale, perhaps?

reubenmorais• 12 years ago

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.

wbsun• 12 years ago

Ah, this is off topic and let me close it to show off my power... hmm, are we on SO?

est5• 12 years ago

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

Ellipsis753• 12 years ago

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

jodrellblank• 12 years ago

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

akx• 12 years ago

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

est5• 12 years ago

How on earth did they guess that?

By acting quickly before 5 other power user close the question, of course.

chavesn2• 12 years ago

That answerer[1] was also one of the close-voters[2]...

[1] http://stackoverflow.com/users/157247/t-j-crowder

[2] http://stackoverflow.com/posts/21947452/revisions

chris_wot• 12 years ago

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

codereflection• 12 years ago

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• 12 years ago

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

RogerL2• 12 years ago

And yet the community did find the answer.

overgard• 12 years ago

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.

anigbrowl• 12 years ago

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?

Disagree. OP failed to exclude some possibilities by doing multiple randomized trials and so on (or at least stating whether he had done so), but he supplied the source code and a description of the behavior that was perfectly adequate to understand the issue. Nothing personal, but your post above is the epitome of deflecting a question instead of engaging with it.

pmelendez• 12 years ago

" What good is a programming problem if no one else can reproduce it?"

Well in real life, those are the tough ones and where help is more appreciated.

The only bugs that I remember are the ones that were random or that nobody else could reproduce and yet were there.

est5• 12 years ago

The post was put on hold because the OP failed to provide the information the community would need to reproduce the issue.

Why close other's question because of your own incompetence? Why the fuck prevent a question from been answered because only five retards can't get it?

Isn't the solemn purpose of the site is to wait until someone who is capable of reproducing it and solve it?

moomin• 12 years ago

Hard to see how the OP could have tracked this down, being unaware of the feature.

talmand2• 12 years ago

I would say if a member with a high reputation has moderation powers then that member is a moderator. They may not have the full powers of an elected moderator, but that would just make them a lower level moderator. It seems the comment can be considered accurate.

ghayes• 12 years ago

If you're interested in this, then please vote in the SO elections, going on now. http://stackoverflow.com/election

RogerL2• 12 years ago

But everyone is saying "elect me and I will close and flag more posts"

boie0025• 12 years ago

"you need at least 150 reputation to vote" - heh

pavanky• 12 years ago

The problem the user was facing had nothing to do with java. I'd say that is pretty much off topic.

cjensen• 12 years ago

It had everything to do with programming, which is on topic.

It's a pet peeve of mine. At least 10% of the time I google for a answer to a programming question it takes me to a StackOverflow question... which has been marked off-topic.

sanderjd3• 12 years ago

How was the user to know that the problem had nothing to do with java without knowing what the problem was? From the user's point of view, the answer could have easily been something like "oh yeah, java prints the 'B' character very slowly for xyz reason".

ZoF• 12 years ago

Usually I understand why a question is marked as offtopic, but I think an issue like this, that someone writing Java is encountering, is definitely on topic.

If a future person were to run into that problem I think that is the most appropriate location for the answer to reside.

unterstrom• 12 years ago

According to this logic, is asking whether this is a java problem also off topic, because it's not a java problem? So you have to know the answer to know if the question is on topic. Great rules.

eieio• 12 years ago

It should be noted that the question has since been re-opened.

Shog9• 12 years ago

They reopened it too. That's what you get when you have a collaboratively-managed site: folks working things out, in public. Nobody said democracy was pretty...

dkersten• 12 years ago

My top voted and most commented on question (IIRC question has 60ish votes, top answer has 90ish, about 20 answers), which I asked five years ago, was closed as off topic about a year ago - FOUR years after 50+ people found it useful enough to vote and comment.

GvS• 12 years ago

My answer with 219 votes was deleted after 4 years by moderator Andrew Barber. It's really disheartening.

CSDude• 12 years ago

I once asked how the old DOS games was written, and they closed because it was not specific enough, although it gained enough upvotes and more than 5 good answers.

raverbashing• 12 years ago

Do you have your answer now?

It was mostly Assembly, Turbo C, Microsoft C or DJGPP in the later games

Making the sound card work -> sucked (especially with interrupts >= 10)

Multithreading -> Non existent / roll your own

Graphics -> VGA or Vesa. Vesa was nice except for one small detail (next point)

Real mode -> Awful! The bane of developers! Going from "16-bit" to 32-bit protected mode is like going from the worse stick-shift car to an automatic modern car.

The reason this also influences VESA is that VGA fits into a segment 320*200 = 64k anything bigger doesn't.

muro2• 12 years ago

Printing random boobs is slow, okay.

muro2• 12 years ago

did you folks read the code?

chj• 12 years ago

good detective work!

tedchs• 12 years ago

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.

VLM2• 12 years ago

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.

fexl• 12 years ago

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

cbsmith• 12 years ago

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• 12 years ago

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

vehementi2• 12 years ago

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.

est5• 12 years ago

who on earth would have thought of

Everyone with >5 years of printf() debugging experience.

yusukeshinyama• 12 years ago

When you're using GNU screen or tmux, you notice that the CPU usage of these processes is sometimes notable.

Here's another way to increase your CPU load with apparently doing nothing:

$ cat /dev/zero

ansible• 12 years ago

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• 12 years ago

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.

delinka• 12 years ago

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

jrockway• 12 years ago

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.

gavinpc• 12 years ago

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

prewett• 12 years ago

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.

agumonkey2• 12 years ago

About that, I wonder how common are path rendering extensions used ( like NV_PATH 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.

GeneralMayhem• 12 years ago

# probably has a decent number of splines in it as well around the corners. It depends on the font, of course, but the Ubuntu font, for example, certainly does.

Why is printing “B” dramatically slower than printing “#”?

Related Stories