One of the first CP/M C's was BDS-C. It's claim to fame was that it compiled the source in-memory, so it was at least that part was nice and fast.
Certainly compared to Whitesmiths C for CP/M, and not just for the $700 price vs $150 for BDS-C. Whitesmiths was real, official C, direct from P. J. Plauger and V6 Unix. But each compile went through many, many, many passes on the poor floppy (including pseudo-assembly "A-Natural" for the 8080 that then translated to real assembly). Everybody complained that while very professional, it just took too long to go through the cycle.
Contemporary BYTE recommendation was to develop & iterate on BDS-C, then at the end re-compile on Whitesmiths to squeeze the best performance.
Which if you come to think of it, fits quite naturally 40 years later, in having combined JIT / AOT toolchains for most compiled languages.
Pity that only Visual C++ seems somehow close to Energize C++ and Visual Age for C++ v4, for that kind of incremental development experience. Live++ and ROOT aren't that widespread.
Also D has a similar approach, use dmd for development, ldc or gdc for release.
Certainly compared to Whitesmiths C for CP/M, and not just for the $700 price vs $150 for BDS-C. Whitesmiths was real, official C, direct from P. J. Plauger and V6 Unix. But each compile went through many, many, many passes on the poor floppy (including pseudo-assembly "A-Natural" for the 8080 that then translated to real assembly). Everybody complained that while very professional, it just took too long to go through the cycle.
Contemporary BYTE recommendation was to develop & iterate on BDS-C, then at the end re-compile on Whitesmiths to squeeze the best performance.