Yes indeed. I develop QEMU at work mainly implementation of new hardware as needed for my employer. It has a software emulator, but it’s not very good. It’s acceptable.
The instruction generation backend does not seem to prioritize performance. Instead, it prioritizes accuracy and ease of maintenance. There is low-hanging fruit for making it faster but there isn’t much interest in doing so for the TCG backend. The attitude seems to be that it’s good enough.
For a small example, you may find it interesting that QEMU does not implement floating point acceleration. It’s done in software even though the host has floating point instructions. It usually doesn’t attempt to use those floating point hardware facilities on the host and instead execute many hundreds of instructions to do floating point using the Berkeley software implementation. Almost never does this matter but it costs a lot of performance. Compare this to the translation performed by projects like FEX and Box64 which do and blow QEMU out of the water for specific use cases.
Another place in the emulator that could be improved is handling of executable pages or cached output of the backend code generator. The executable code caching mechanism is very simple and could probably be much more aggressive on today’s systems.
If you examine change logs, TCG really doesn’t get much TLC last time I checked. It could be a better emulator but performance outside of KVM use case is not as important to the project.