Eclipse has IMHO the best configuration for selecting the files to tag with the "Derived" folder property. I am willing to put up with fact that it is slower and buggier than most of the competing solutions primarily because of how much easier it is to manage tagging for large projects. The indexer itself is slow for C/C++ files and fairly buggy (both the quick and full versions tend to hang on large projects a lot).

http://www.mojavelinux.com/blog/archives/2006/03/eclipse_resource_filtering_using_derived/

For extremely large projects, I still tend to use Visual SlickEdit (fairly expensive). It is extremely quick when updating tags for extremely large projects. I would prefer to use a cross platform open source editor, but none of the ones I have evaluated can match it in speed yet. Eclipse looks promising and might be able to close that gap in the future.

In terms of feature set, I am not aware of anything that can separate reader tags from writer tags like Source Navigator is capable of. The project was abandoned a few years ago, but some new maintainers have recently made a new release.

http://sourcenav.berlios.de/

If you do any work on headless servers or embedded systems, you will likely have to pick a console editor like vi or Emacs along with cscope in addition to whatever GUI tools you choose.

I've run into the problem of terrible STL performance in more than one occasion. The problem isn't so much that's impossible for it to be as efficient as C, in theory it could be. But to date compilers are more likely to turn a pointer simple assignment like tail->next=new into a single instruction store than pages upon pages of accessors calling accessors to call into templated functions in order to do the same.

If your idea of high performance is that both operations need to take less than a second, then you won't notice STL vs C performance differences. But if you need to guarantee that all of your array / vector / list operations complete within a few hundred processor cycles, optimizing STL is typically more work than replacing the entire thing with C code (including the extra debugging that doing the code in C will likely entail).

One of the things related to GCC performance is that you can use the LLVM C backend to generate C code from the C++ STL template source code. If you feed the C code back into GCC you can see huge speed gains with the compiler optimizing loops significantly better than if you feed it the C++ code directly. The downside is that debugging the LLVM generated obfuscated C code is a royal pain.

This is wildly dependent on whether your function call needs to store parameters on the stack and how slow a load-hit-store operation takes on the processor in question. Recent x86 processors are heavily optimized for these types of operations, but you cannot assume that the only platform your kernel is going to run on is x86 based.

You can easily execute 50+ non-dependent math operations in the amount of cycles that a single load-hit-store can take on a processor that isn't as heavily optimized as x86.

This is also one of the reasons why algorithms in C that do not need to reserve an extra register for the "this" pointer can easily outperform the same code written in C++ that requires the use of "this" pointers. With OOP in C++ you need to write everything as "statics" in order reduce the number of registers needed per function call to match the performance of C (GCC is rapidly improving lately and soon this may no longer be necessary).

Storing information on the stack from a register and reloading that same information near the top of the callee is very similar to what is described with float to integer conversions in the article below.

http://assemblyrequired.crashworks.org/tag/lhs/