With either technique you are in some sense "constructing the HTML" for every request. As soon as you make use of, for example, dynamic links, you can't use static HTML any more, and need to have your web application render your page, for example as ASPX. For both "standard" ASPX and an MVC approach using Razor templating, the Page is compiled at first use and thereafter the compiled version is used. With a DD4T approach, you will be retrieving the data from the broker, but if it's set up correctly, most of the time, the data will be retrieved from memory cache.
The bottom line is that for any performance analysis in as complex a situation as a modern web application, there are too many variables to be able to guess which will perform better. You'd need to measure both approaches, and it's quite likely that the most important influences on performance will not be the rendering of the HTML.
In any case, the costs and benefits might not be about which approach performs best in a laboratory test. For example, the business you are supporting may value agility and maintainability, and even if you needed more powerful hardware to achieve the same performance (and as I said, this is not necessarily so) there could be business benefits from investing in an MVC architecture.
Most businesses these days would like to be able to deliver new web functionality in short focussed sprints, with assured levels of quality in the delivered software. Over the years, we've developed various techniques that make automated testing of content manager templates possible, but it's never been a comfortable fit. Moving your templating to the web application allows you to use mainstream industry techniques for unit testing and the like.
Testing is just one example that shows how the trade-offs between architectures end up being about more than simply the speed of rendering your HTML. The rendering speed will most likely be fine in any case, but you should probably also be focussing your thoughts in other areas.