Most of this impression is usually caused by the combination of the following things:
* fast startup
* programs in C usually do much less with more code than high level languages
Once the project gets really big and complex, C starts to get slower and harder to optimize than some higher level languages (e.g. dynamic dispatch tends to be slower in C than in C++ or Java).
>>programs in C usually do much less with more code than high level languages
Ok. So?
>>Once the project gets really big and complex, C starts to get slower and harder to optimize than some higher level languages
True. The speed boost isn't automatic. It's up to the programmer to write fast code.
I have nothing against high-level languages and garbage collection. They certainly have a place. But if you use high-level languages exclusively, you'll never (or rarely) have the special joy of seeing your program run at the full speed of the hardware.
There bigger a project is, the more stuff it does. If a language does this stuff slow(aka ruby), then it will not run faster no matter what buzz words you invoke.
It can't be as fast as in VM-based languages, because the code (typically) can't self-optimize / modify itself according to the usage patterns to inline dynamic calls. This is the stuff that VM can do, because it has much more information. This is one of the reasons a general sorting method like qsort is so slow in C compared to general sorting method in Java (Collections.sort). Sure, you can specialize manually or do some macros, but such manual approach gets hairy pretty quickly for something more complex than a simple sorting method.
std::sort in C++ is known to be faster than qsort() in standard C, because C++ templates allow the comparison function to be inlined. I find it doubtful, though, that Java has a generic sort method that regularly outperforms qsort.
I measured Collections.sort and it was ver close to C++ std:sort in performance, while C qsort was about 10x slower. It outperforms qsort for the same reason C++ does it - the call to comparison function is inlined.
There is a theoretical benefit in being able to optimize at runtime. But, in practice, these advantages are virtually always too small to outperform code compiled statically.
This is not a theoretical benefit - it is a very practical benefit, especially for object-oriented code with lots of indirection, virtual calls and dynamically loaded code. The reason it is not visible in microbenchmarks is because microbenchmarks are small and usually avoid indirection as much as possible, and even if there exist some, the code is all in one file so a static compiler can figure out all the call targets properly.
There is nothing about pointers that makes them unusually hard to keep track of. If you are prone to goofing on pointer arithmetic, then you're almost certainly going to run into problems even if you never use pointers, because arithmetic is hard to avoid in programming.
I don't use C for everything. When I do write C, I try to keep memory as simple as possible. I avoid allocating dynamic memory wherever possible, and when I do use malloc, I try to keep the logic around the pointers as simple as possible. This is beneficial all around, because malloc and free are not especially fast, and if you use them for everything, you won't see all that much benefit over a high-level language.
It's like building your own house or making your own clothes. There's no guarantee that you'll do a better job and get a better result than if you went the easy way.
First of all, in other similar languages like Modula-2 and Ada, there is no need to use pointer arithetic as much as C developers do.
Even in C, most developers that use it, are doing micro-optimizations without ever testing their assumptions in terms of performance.
Finally, as a single developer it is easy to keep track of most C traps, the problem is when a project has more than a few developers, with different skill levels. Then the party starts.
There are probably lots of people writing bad code in C, I'll grant you that point. But that isn't a property that's built into the C language itself. I think you are attacking a straw man. My original point was just that it's possible to write very fast programs in C.
>It is, as it makes very easy to blow your leg off.
I have never seen a bug-proof programming language. If a language lets you do anything at all, then it will let you write bugs. So I don't see it as a weakness that C allows you to write bugs. If you have easy access to memory, then you can easily corrupt memory.
