"The time it takes to load the framework and compile the program are often much more than the time it takes to execute the program, and the runtime framework may use more resources than the program itself when running. Programs using such a framework sometimes have unacceptably long response times for simple tasks like pressing a button or moving the mouse."
When efficiency is important, the startup time of the VM hardly matters. Even if it would, the issue is not loading the Framework (class library) but JIT compilation. And, no, simple tasks like clicking a button will certainly not cause any observable delay due to the language.
Java and C# are very fast for certain problems, but running 'for i in *; do java MyProgram $i; done' in a large directory is decidedly less pleasant than it would be with the same program written in e.g. C. For very small programs, msot cycles are indeed not spent on the program itself.
(Of course, looping in that way is still inefficient when your program is written in C.)
Clicking a button shouldn't cause a noticeable delay on vaguely modern hardware, I agree.
These are invaluable references -- I hope we have many people here familiar with them, or new readers appreciating them.
It's a shame that nothing quite so comprehensive exists for IO, as network and storage accesses, patterns and quirks are often more of a bottleneck than CPU, for many applications.
"The time it takes to load the framework and compile the program are often much more than the time it takes to execute the program, and the runtime framework may use more resources than the program itself when running. Programs using such a framework sometimes have unacceptably long response times for simple tasks like pressing a button or moving the mouse."
When efficiency is important, the startup time of the VM hardly matters. Even if it would, the issue is not loading the Framework (class library) but JIT compilation. And, no, simple tasks like clicking a button will certainly not cause any observable delay due to the language.