Phalcon 1.x to 2.x upgrade began to consume all RAM - how to get around?

Question

PHP

Good time!
A typical response from the API consists of 100 objects and + 3 related objects for each (total ~ 400 minus duplicates).
On Phalcon 1.3.6 the API responds within 1 second and consumes several MB of memory. XhProf claims that the brake is \file_existsin the composer's autoloader (-:
On Phalcon 2.0.10 , the same request starts tinkering: the API responds for 30-60 seconds and eats up all available memory (1 GB of RAM + 1 GB of swap) and the entire CPU core. XhProf shows that brake is \ReflectionClass::getProperty, and traces lead to \Phalcon\Mvc\Model\Resultset\Simple::current.Has anyone
encountered this?Is there a solution/workaround?
Repeated on Ubuntu 12.x/14.x, PHP 5.5.x, PHP 5.6.x (`ppa:ondrej/php `), PHP 5.6.x (`ppa:ondrej/php5-5.6`, deprecated).
ps: unfortunately, extracting from thephppleague/fractal project in such a way as to form exactly the same answer for this request is too time consuming and not very clear. Of course, I can use \Phalcon\PDO::execute()one SQL query to select all the necessary data, but I'm sure that this will not show anything about the reasons for the brakes after the upgrade.
UPD: https://github.com/phalcon/cphalcon/pull/12131 - This PR will apparently be merged into 3.0.1 and fixes SUBJ.

Answer 1

As part of this pull request , a check for the visibility of fields through Reflection has been added. There was no such functionality in 1.3.2 , that's why it worked quickly.
Tellingly, version 1.x used the getModelsMetadata method for this, which returned data about the fields (which, by the way, was also cached), and in 2.x this was removed and a stupid call to Reflection was added. For a production-ready high-speed framework, this is the wildest thing.
As an answer to the question of what to do, I can advise: define setters. Then the code will enter the _possibleSetter block and execution will not reach _isVisible. It's a crutch, but it should work.
You can also override __set in your base model class. Something like:

public function __set($property, $value) {
    if (is_array($value) || is_object($value)) {
        return parent::__set($property, $value);
    }
    if ($this->_possibleSetter($property, $value)) {
        return $value();
    }
    $this->{$property} = $value;
    return $value();
}

But this is at your own peril and risk, since the validity of the properties will not be checked.
Well, write them an issue, of course