Performance improvement (Eloquent): Prevent duplicate database hits by leveraging WeakReference

[jf-m]

Hi everyone,

In my latest work project, I extended Eloquent's Model class to create a system that prevents some duplicate database hits by using PHP's \WeakReference. It has been purposely limited, but it succeeded in increasing the overall performance of the project.

I believe I can create a more generic version of this that I could submit to Laravel core as a PR to enhance Eloquent's performance greatly (depending on each case and usage of Eloquent, of course). But before engaging in this work, I'd like to have the input of the community and know what do you think of this suggestion.

Before

To put it simply, here is what Eloquent does right now:

$author = Author::find(1); // The first author is named "Foo".
echo $author->name; // Will print "Foo"

$article = $author->articles->first();
echo $article->author->name; // ❌ This line will generate a database hit (select..) to fetch the Author from the database and print "Foo"

$author->name = "Bar";
$author->save(); 

echo $article->author->name; // ❌ Will print "Foo" => Old data, incorrect
echo $author->name; // Will print "Bar" => The latest database's value

So there are two points that my suggestion will address. The first point is the main focus, the second is just a beneficial side effect of my proposed solution:

1. ❌ The line 4 generates a database hit (select * from authors where..) that could have been prevented because the data is already there, in the $author variable that was used to retrieve the $article object.
2. ❌ The line 7 prints an incorrect value, which is expected because $author does not refer to the same object as $article->author. Again, this could be prevented by storing a weak reference to the parents' object ($author in this case).

After

With my suggestion (and hopefully a PR), here is what it would look like:

$author = Author::find(1); // The first author is named "Foo".
echo $author->name; // Will print "Foo"

$article = $author->articles->first();
echo $article->author->name; // ✅ This line will not retrieve data from the database, no database hit. It will use a reference of the $author object instead.

$author->name = "Bar";
$author->save();

echo $article->author->name; // ✅ Will print "Bar" => The latest database's value
echo $author->name; // Will print "Bar" => The latest database's value

To sum-up, now:

1. ✅ $article->author is, in fact, referring to $author through the use of a weak ref. Therefore, there was no need to retrieve the data from the database.
2. ✅ $article->author is referring to $author, therefore the name is the latest value.

Implementation

This system is currently well-tested and implemented in live in my current project. I created a custom EloquentWeakReference wrapper class, serializable, and that includes a failsafe that will do a database hit if the object has been destroyed. The use of a weak ref allows to safely store references to parent's object within children without risking a circular reference issue.
I also had to use PHP reflection to discover all the Eloquent relations of an Eloquent object. To prevent using Reflection in the live system, I created a new cache command that caches the required information for EloquentWeakReference to work.

Disclaimer

By implementing this new way of storing eloquent's model relation, Laravel developers will have to be aware of what it means in terms of object reference. Indeed, one might expect that the line 7 should print the old "Foo" data because this is what Eloquent's has always been doing rightly since ever.
Therefore, if implemented, it might have a moderate to high impact when upgrading Laravel.

Discussion

Now, the discussion is open. In my particular case, this change was a no-brainer, with massive performance improvements and an immense reduction of the database workload. But there might be considerations that I am missing that might justify that it should not be in Laravel core, in which case I might create a composer package for it.

What do you think?

[henzeb]

I think it should be a trait, so anyone can implement this on their own accord ... Then it's not a breaking change ...

[jf-m]

Yes, definitely right, either a Trait or an interface to "activate" this feature would make much more sense.

[ghost]

I remember reading about something similar about problem 1 on which a problem would be memory leakage ( because of the eager loading). Linking the parent and child in a circle by default seems not ok to me.

Imagine a list GET / resource that will be retrieved with relation
That means that each resource row will have its relation and also its relation would have its parent in it. The mirror in mirror effect.

[jf-m]

Memory leakage can be avoided by preventing N+1 relations in toArray/toJson and in serialization (or a more complex solution, see below).

Eager Loading

The way I see it (correct me if I'm wrong), we could solve that by considering eager loading as higher priority over this new "feature". Meaning that if the developer wants to eager load, example using Article::with('author')->get(); then the database hit will retrieve both author and article, and this new feature won't be used.

In all the following cases, this new "feature" must not be triggered, and I believe it makes sense:

$author = Author::find(1);
$article = Article::find(1);

$article->author; // DB HIT and it makes sense here, because $author was never used to retrieve $article.
$authos->articles->first(); // DB HIT, same, it makes sense again for the same reason.

$article = Article::with('author')->find(1);
$article->author; // DB HIT, again it makes sense to me.

Serialization / relationsToArray

Solution A:
If the developer decides to use this proposed feature, then he must be made aware that serialized relationships will come without their own relations (so N+1 maximum, the child will not have its parent in the serialized data).
Concerning Laravel serialization (when using Queue or Job for instance), it won't cause any issues at all, and if a N+2 relation is ever requested, it will be retrieved from the database seamlessly.

Solution B:
We could create a $this->relationsWeakReferenceArray in Eloquent's Model that stores the relevant weak references, and only when a relation is accessed, then we store its related weak reference from $relationsWeakReferenceArray into $relations with a flag stating that this weak ref has been accessed and must be serializable/jsonable (again, without its own N+1).

It would look like that:

$author = Author::find(1);

/**
* Here a EloquentWeakReference of `$author` will be stored in
* the private $article->relationsWeakReferenceArray, 
* but the relation `$article->author` will remain empty until accessed.
**/
$article = $author->articles->first();

/** 
* Here the `author` relation is accessed, 
* therefore the weak reference is pulled from 
* `$article->relationsWeakReferenceArray` into `$article->relations` 
* and a flag boolean in this EloquentWeakReference is set to true.
**/
echo $article->author->name;

/**
* Because the relation `author` has been accessed above, 
* the `$article->relations` contains a EloquentWeakReference with the flag to true
* Therefore in `relationsToArray` it will ask the EloquentWeakReference to have a 
* json version of `author` without all of its non-flagged relations with EloquentWeakReference
**/
$author->toJson();

I'm not sure to be 100% clear, don't hesitate to correct me if I'm wrong or tell me if I'm going to far.

I still believe it would be a great addition to the framework and that something can be worked out to achieve the desired result. There's a great potential of performance increase and reduction of db hits.