Feature: asynchronous `endProbe()` to reduce overhead

[SilverFire]

Say we have the following method:

class Client
{
    private function profile(\Closure $closure): Profile
    {
        $blackfire = new Client();

        $config = new Configuration();
        $config->setTitle('Daemon run @ ' . (new \DateTime())->format(DATE_ATOM));
        $config->assert('main.wall_time < 1s', "I'm working pretty fast");

        $probe = $blackfire->createProbe($config);
            $closure();
        $profile = $blackfire->endProbe($probe);
        echo ' 🌟 Profile done: ' . $profile->getUrl() . "\n";
    }
}

Calling endProbe() sends data to the agent and always waits for the result, meaning that:

1. The process is blocked when uploading a profile to blackfire.io
2. It relies on networking
3. It creates an overhead if I'm just profiling random requests and don't need to know the result of the assertion right away.

It would be nice to introduce a new API:

public function endProbeAsynchronously(Probe $probe): ProfilePromise;

1. The method passes the probe to the Agent
2. The Agent assigns a UUID for that probe
3. A ProfilePromise DTO is returned, carrying the assigned UUID

The ProfilePromise API should be further discussed.

[lolautruche]

Thank you for the suggestion @SilverFire!

What do you think @romainneutron @iamluc ?

[iamluc]

endProbe() does not block until the profile is uploaded to blackfire.io, it just blocks until the probe has sent the data to the agent which is something fast.

But then calling $profile->getUrl() (or any method on the $profile object) will wait until the profile has been processed. So I you don't need to know the result of the profile, you can just discard the $profile object.

[SilverFire]

Aw, that's nice :) I've just checked the implementation and it really works as described.

Maybe, it makes sense to add Profile::getId() method that will return the UUID without calling the initializeProfileCallback?

[iamluc]

Maybe, it makes sense to add Profile::getId() method that will return the UUID without calling the initializeProfileCallback?

Yep, it could be a good addition. Could you open a new issue for this? Then I propose to close this one.

[SilverFire]

Done