3 ms·

I agree with you about the "interesting things", but those aren't the majority of things by a good margin. The overwhelming majority of code written today is li

I agree with you about the "interesting things", but those aren't the majority of things by a good margin. The overwhelming majority of code written today is likely limited primarily by I/O, such as waiting on user input, network speed, disk speed, &c. Also, most slower languages these days are explicitly designed with the ability to call into code written in a faster language, which means that with some profiling and a few dozen lines of C many applications can get 90+% of the speed of a fast language while still being written almost entirely in the trendy interpreted language of your choice. Which reminds me, how many people in "the real world" actually profile their programs? I bet a lot of performance gains could be found that way in any language.

silentbicycle 17y ago
> Which reminds me, how many people in "the real world" actually profile their programs? I bet a lot of performance gains could be found that way in any language. Not enough, I'd say. Particularly since just scrutinizing the first few things a profiler catches can make a tremendous difference. For example, in an hour of profiling and tuning a project of mine, I fixed two hotspots that each led to an independent 20x speedup. 400x total. Half the runtime is just disk IO now.
fauigerzigerk 17y ago
The reason why the interpreted language + C = 90% speed equation has never quite worked out for me is that much of the speed advantage of compiled languages comes from lower memory consumption. Python's __slots__, collections.namedtuple, array and struct modules do help a lot to reduce memory consumption. Sadly, it's not nearly good enough to write significant parts of my code in Python (which I would love to do)