As ASP final code is in c++ it's the fastest way of handling data.
Ceteris paribus, assembler will generate the fastest code, followed by C, and a few other similar bare-metal, statically-typed, non-object oriented languages. But then again, the speed of the algorithms very quickly trumps the speed of the code.
For example, looking up data in a hash or a btree, will eventually always outperform, scanning an entire array of the same data. Beyond a certain size, the program using a hash, even when written in the slowest possible language, will outperform the program scanning a table, written in the fastest hand-optimized assembler.
We can safely state that sites are almost never slow, because of the slowness of the language in which they were implemented, but because inefficient algorithms are being used in performance-critical points (deeply nested innermost loops).
Furthermore, CMS systems like Joomla and webshops like Virtuemart, spend most of their serverside CPU cycles inside the database, retrieving data through the SQL language. The database engine (MySQL) itself is written in heavily optimized C and uses relatively efficient algorithms (not always, though).
If you want to see massive performance gains in this kind of systems, the way to go is to look at whether the SQL queries are optimal in terms of performance, the recommended indexes are present, and whether caching is sufficiently well configured.
In my experience, the Joomla and VM queries are quite well done, and most of the recommended indexes present. I haven't seen any low-hanging fruit in that respect in the Joomla or VM source code. Concerning caching, it is up to site admin to configure this in a judicious way.
Magento's lacklustre performance and lack of scalability, however, cannot be salvaged. That thing will always and forever be slow, no matter what you try, and the more data you load, the worse it will get. Indexing hardly helps, because the queries generated in an EAV context are so complicated, that the database engine can hardly ever compute correctly what alternative access strategy would avoid the costly (entire) table scans, for which EAV databases such as Magento, have become notorious.
Facebook is written in Php and scales perfectly well, regardless of the fact that it is being pounded by 300 million users. As you can see, the problem is really not Php. As stated above, the problem is almost invariably elsewhere.