A little later, Turbo Pascal ran like greased lightning on a 386 or 486 box. There was really nothing else like it, which is partly why it enjoyed such immense popularity.
Turbo Pascal compiled fast. The generated code ran at more or less the same speed as output of random other compilers.
Object Pascal is an extension of Pascal. For instance, many of Apple's Object Pascal extensions were incorporated into Turbo Pascal. From Turbo Pascal version 5.5 and up, it is Borland's version of Object Pascal. You can use Objects and do OOP in Turbo Pascal.
TP 3.0 generated COM files (near code, near data, far heap-allocated data).
TP 4.0 generated EXE files (far code, near data, far heap-allocated data).
(the above is "to the best of my recollection": I no longer have the manuals for these toolchains; it might be the case that in TP 4+ all data is far (pointers to data were far)).
A TP coder was generally forced to live within these constraints (and adapt to the memory model changes described above across the 3 -> 4 transition).
Turbo C 1.0 came along within a year or so of TP 4.0, and (because it was actually not a 1.0 implementation but a rebranding + enhancement of an existing toolchain acquired by Borland) supported all permutations of x86 memory models, allowing the coder to choose according to their needs (and explicitly define near and far functions and data as needed independent of the memory model used w/o a need to drop into [inline] asm).
Turbo C's giving the programmer total control and optimization flexibility along these axes, which was a function of the language _implementations_, not the languages themselves, I believe contributed to the "C was faster" outcome (from TP 4 onward, there was (inline asm aside) IIRC no way to instantiate near functions). Turbo C was not the only C implementation for MS-DOS, but IIRC it immediately became the most popular, and held that crown for many years; other entrants needed to match Turbo C's features or die.
[edit]
Microsoft offered a MS-DOS C compiler (long?) prior to the release of TC 1.0, which supported the same memory-model permutations as TC 1.0. However it was at least 3x more expensive than TC 1.0, so when TC 1.0 was released at such a low price, it grabbed a lot of market share (by expanding the market to include programmers with smaller budgets). There were at least a few more MS-DOS C toolchain competitors already on the market when TC 1.0 was released (but I never used them so cannot comment futher on them).
And Turbo C 2.0 was quickly replaced by Turbo C++.
I didn't miss them, but because IIRC all the versions you mentioned (and also Delphi 1.0) were x86 16-bit (only) Borland/Turbo Pascal evolutions having effectively the same memory model support as TP 4.0, felt they were not important to enumerate. These releases certainly added other features, but IIRC made no architectural changes affecting the performance of their generated code on the 16-bit x86 platform.
(Again IIRC) all Borland C/C++ variants >= TC 1.0 offered the same 16-bit x86 memory model (and ability to manually mixing memory models) support (that already being comprehensive), with gradually improving codegen optimizations.
My larger proposition is that the perception of (Turbo) Pascal's performance being perceived as poorer than that of C (in the interval when Pascal was being eclipsed by C/C++), while accurate, was influenced to some degree by the incidental factor of the dominant x86 CPU architecture of the day having a segmented architecture upon which extraction of optimal performance across the range of applications necessitated the extensive/comprehensive memory model support found in all competitive C/C++ compilers of that day, which none of the competing Pascal compilers (which is to say: Borland's plus MS' QuickPascal (which implemented the Borland language definition [1])) possessed. It would have taken those Pascal vendors more resources to add such memory model support (and other optimizations offered by their C/C++ competition), and they elected not to do so. Borland moved on to Delphi which continued the pattern wherein raw performance of the Pascal compiler's generated code (x86 32-bit as well as 16-bit) lagged behind that of the C/C++ competition; Borland's finite resources were expended on the IDE & RAD aspect of Delphi rather than on codegen. "The rest is history". But I don't think there was anything intrinsic to Borland's Pascal dialect (the only one I ever used) which doomed it to take a backseat to C in terms of performance: I used both TC and TP 4+ without ever feeling a vast difference between the two languages (and found many aspect of Pascal preferable to those of C/C++).
Borland Pascal 7.0 introduced support for protected mode.
The Turbo C 1.0 User's Guide [1] page 244 (257) "Turbo C's Six Memory Models" lists these as tiny, small, medium, compact, large, huge. Also, page 220 (233) "The near, far, and huge Modifiers".
You claim that these same capabilities were present in TP 5.0, 5.5, 6.0, 7.0 and TPW 1.5. Can you provide a reference for that?
[1] http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/tur...
In the eighties C was considered slow. If you needed performance, you coded (the relevant part) in assembly (or machine code). C actually allows you (for the better or worse) to incorporate assembly code right within a C program, a desirable feature then. Turbo Pascal (on CP/M) only offered the same for machine code.
While I was fond of Turbo Pascal in its days, C was just so much more flexible.
Borland compilers were basically the same, and if one cared about speed, the only way to achieve it was hand written Assembly.
I'm a Delphi developer, and have spent about 24 of the past 36 years programming in Pascal. The Delphi XE7 compiler (now about 8 years old) can on a one year old Lenovo laptop with 16 GB RAM compile 1.35 million LOC (in 80 different files) in 11 seconds. The 64-bit compile takes roughly twice as long.
One of the design features of Pascal was a one pass compile which explains the speed. Note also that the Delphi/Turbo Pascal compilers are smart and discard all unused code.