For CPU bound threads this is the case, but if threads are waiting on IO or get to sleep, this is not the case. More threads than cores can sometimes even be a winner for CPU intensive programs if physical memory is the bottle neck under some circumstances (swapping memory to disk is IO that might need to make a thread take a nap). It's nice when you can design for nearly 1-to-1 thread/core relationships, but it's often quicker (in terms of developer time) to mostly write all threads in a style similar to stand alone programs rather than to separate everything into queueable tasklets that don't sleep (they never sleep! but they do run to completion and often schedule a continuation tasklet to handle results of an IO operation or to start up after a given passage of time).

The profiler can't tell you how to make your bubble sort faster, only that if you made it faster that would have a major impact on run time (for large data sets). It wouldn't tell you what methods to use to achieve this additional performance, but it would be able to help you understand how and why adding more code sped up the sort (because it executed each piece of code less often).

I rarely use profilers, but there are a few cases when even good programmers may have trouble seeing where code is slow. Sometimes there may be a library call which you think will be fast, but turns out to be slow. This could be due to system call(s) that take longer than the programmer realizes or due to the library function's algorithm working very differently than the programmer realized. We all make assumptions about things that sometimes aren't true. One very big issue is using something like using strlen(some_string) as a constant in a C program. Many programmers use that as though it is a constant in the compiler's mind, when it may not be (GCC has an __attribute__ that lets the compiler see that it is, but it's not standard). That's the kind of thing that could end up in a loop, possibly as part of the loop check, without many programmers realizing that it's a problem. While you might see that code, there are similar circumstances which are less obvious. These are often the results of invisible code introduced by compilers for languages higher than C. Overloaded operators, copy constructors, and destructors can all have much more impact on code than programmers realize. Knowing what kinds of things your language may hide is a good way to avoid these, but some things still slip through. Other things that are easy to miss is how contentious locks, semaphores, mutexes, and other blocking operations are. These are difficult to figure out sometimes. There are also times when you need to demonstrate to someone else where the bottle necks in code are. If your cocky junior programmer weren't your subordinate but rather your boss then the output of a profiler would be something that you could use to combat the cockiness. This is particularly useful when you get "Your code is slow! Fix it!" and you can come back with "This external code/hardware/whatever, which isn't under my control, is what is slow." Another time when using a profiler would be very useful would be if there were disagreement or uncertainty over which of multiple parts of a program were responsible for the different amounts of the slowness. Maybe you need to prioritize the order in which these are addressed. For you or I it may be obvious that a section of code is slower than it has to be, but when comparing two suboptimal sections of code it is very often that eyeballs alone are not enough. There are also times when a profiler can be used to find bugs that would take a lot of stepping in a debugger to locate.

I like stackoverflow.com, though I have seen some limited behavior like you described. Many users are way too quick to down vote both questions and answers. I've used the site for several years and have only down voted once or twice. I reserve that for extreme circumstances such as abuse or repeating the same problems many times while ignoring question asking advice from other users. There are a few recurring issues that people have with asking questions on there that could be helped with better research and communication skills by the askers of questions. Sometimes there are disagreements about exactly what does qualify as a suitable topic for SO (or it's sister sites) as well as the tags used for questions. Once I asked a question on there about the using sed. Some people may have considered that question to have not been on topic because it wasn't enough of a programming question, but it was answered. If I had been asking a general user question, such as "How do I run a program on Windows 98?" then I'd probably have been down voted because it wasn't a programming question (and because it mentioned "Windows 98"). Asking a question on SO should almost never be the first thing anyone does when a question comes to mind. When you post a question there it takes up other people's valuable time to read, consider, research, and answer (ignoring the time that it takes for someone to down vote), so if someone asks a question on SO that could easily have been answered by Googling then people are likely to down vote that question because they take it as disrespectful of the value of their time. If someone does look for resources and is still confused, or even confused by the resources, then cite those resources in your question. If no resources can be found, mention what you've searched on (the keywords). It is quite common that people are calling a concept the wrong thing or at least something other than what it is commonly known as, which can make searching and asking questions not work out well. SO is in English, so make sure that you're English is readable. It would be nice if native language wasn't an issue, but it is. If you're question makes no sense grammatically then it will be misunderstood, ignored, or down voted. People on SO will try to help fix up questions like this, and the asker needs to check back to read the changes, suggested changes, and pleads for clarity that other users have posted. Personally I often find it easier to read broken English if I know what the writer's native la