In Laravel 5.2, how much performance will be improved if DB facade is used instead of Eloquent ORM?

See the 2016 version of the Laravel series introductory tutorial (1) here is a paragraph:

Eloquent is Laravel’s ORM, and it is the most powerful place in the Laravel system, bar none. When the original Laravel author was developing the first version, it took a full third of the time to come up with Eloquent. Of course, "if you want to practice this skill, you must first go to the palace." Eloquent is also the slowest place in Laravel and cannot be solved so far. (Performance problems caused by routing, automatic loading, scattered configuration, and views are almost completely solved through caching)

Is this indeed the case? Can using cache (such as redis) solve Laravel's performance problems, except Eloquent ORM?
If you use the DB facade instead of Eloquent ORM, is there no need to create a Model? In other words, MVC has become VC?

Reply content:

See the 2016 version of the Laravel series introductory tutorial (1) here is a paragraph:

Eloquent is Laravel’s ORM, and it is the most powerful place in the Laravel system, bar none. When the original Laravel author was developing the first version, it took a full third of the time to come up with Eloquent. Of course, "if you want to practice this skill, you must first go to the palace." Eloquent is also the slowest place in Laravel and cannot be solved so far. (Performance problems caused by routing, automatic loading, scattered configuration, and views are almost completely solved through caching)

Is this indeed the case? Can using cache (such as redis) solve Laravel's performance problems, except Eloquent ORM?
If you use the DB facade instead of Eloquent ORM, is there no need to create a Model? In other words, MVC has become VC?

First of all, I have to complain. Many documents of Laravel like to overextend. For example, in the paragraph above, Eloquent and PHP in other ORM frameworks all have a similar flavor, and there is nothing particularly awesome about it. In addition, it does take a lot of time to develop ORM, mainly because the logic in ORM is much more complicated than other components, but you can’t say how long it takes to make a difference...
Secondly, ORM is not equal to Model, you can still do ORM without Model. For example, my framework Beaver (https://github.com/funcuter/beaver) is designed with Model, but it has not been installed yet. (As mentioned above, ORM is easy to use, but its performance is poor. I am disgusted by things with poor performance). In my design, ORM directly operates Model, bypassing the DB layer, and normal operation can still be achieved. ORM

Model is more like a SQL query set of modules that you split out. So if you understand it this way, it is actually your choice whether to use M, just like in the early days, SQL statements were written directly on the page. If you care about performance so much, you can also directly use DB to execute native SQL as mentioned above.

The design ideas that will not improve Laravel are destined to be synonymous with low performance. This is purely to prove that PHP can actually use design patterns. In fact, the performance is at the bottom, and the performance is at the same level as zf. In fact, in terms of design patterns, zf is better Be stronger

Not taking sides or showing off, just discussing technical issues

https://phphub.org/topics/1396 Measured data of the same machine configured with different frameworks