In Laravel 5.2, how much performance would be improved if the DB façade was used instead of the eloquent ORM?

See the 2016 version of the Laravel series Getting Started tutorial (a) Here is a passage:

Eloquent is the Laravel ORM, the most powerful place in the Laravel system, not one of them. The original Laravel author in the development of the first version of the time spent a full one-third to get out eloquent. Of course, "to practice this work, must first self-palace", eloquent is also the slowest place in Laravel, so far cannot solve. (Routing, auto-loading, configuration dispersion, view-raised performance issues are almost completely resolved through caching)

Is that really the case? Using caching (such as Redis) to solve laravel performance problems, in addition to the eloquent ORM?
If the DB façade is used instead of the eloquent ORM, is it not necessary to create the model? Which means MVC becomes VC?

Reply content:

See the 2016 version of the Laravel series Getting Started tutorial (a) Here is a passage:

Eloquent is the Laravel ORM, the most powerful place in the Laravel system, not one of them. The original Laravel author in the development of the first version of the time spent a full one-third to get out eloquent. Of course, "to practice this work, must first self-palace", eloquent is also the slowest place in Laravel, so far cannot solve. (Routing, auto-loading, configuration dispersion, view-raised performance issues are almost completely resolved through caching)

Is that really the case? Using caching (such as Redis) to solve laravel performance problems, in addition to the eloquent ORM?
If the DB façade is used instead of the eloquent ORM, is it not necessary to create the model? Which means MVC becomes VC?

Many of the documents that first have to be spit out Laravel are like over-expansion, such as the above paragraph, Eloquent and the other PHP frames are similar in ORM taste, there is no special cow place. In addition ORM , the development does take a lot of time, mainly because ORM the logic is much more complex than other components, but you can't say how long it takes to feel the sky.
Second, ORM not equal Model to, nothing ORM can be done Model , for example my frame Beaver (https://github.com/funcuter/beaver) is designed Model , but so far not on ORM (as said above, easy to use ORM , but poor performance, my poor performance of things more offensive). I design the Model direct operation DB , bypassing ORM this layer, the same can achieve normal operation.

The model is more like a collection of SQL queries for the modules that you split out of, so it would be better to use m as a choice, just like in the early days when SQL statements were written directly on the page. If you care so much about performance, then you can do the native SQL directly using the DB as described upstairs.

will not improve the design of laravel is destined to be synonymous with low performance is purely to prove that PHP can also be used in design mode, in fact, performance belongs to the bottom, performance and ZF a level, in fact, on the design model, ZF stronger some

Not for queued, not for loading, just to discuss technical issues

https://phphub.org/topics/1396 the same machine to configure the measured data of different frames

