Version 2.1.0 takes a very long time to render errors

[patroniton]

I'm using Laravel 5.2 and when I call return parent::render($request, $e); in the render method in App\Exceptions\Handler.php it takes a very long time (2-3 minutes) to display the error page. My CPU usage also spikes to 70-80% while it's running.

I'm also using Graham's Laravel Exceptions package here.

If I catch my own exception or return from the method without calling return parent::render($request, $e); then the page renders as expected.

This doesn't happen in version 2.0.0, so for now I'm going to keep using that. If you need any more information from me on this issue I'll try my best to provide you with it.

[GrahamCampbell]

I assume this is because whoops 2.1 is trying to dump some heavy ass objects, and that's taking ages.

[pelim]

same issue 100% cpu

[staabm]

could someone create a blackfire.io profile for such a slow case and share it here?

[denis-sokolov]

@jonasdt, would you please take a look at this, and whether it is related to #387?

[jonasdt]

Check #396, for Laravel you can use something like

$handler = new PrettyPageHandler();
$handler->setApplicationNamespaces(['App\\']);

It probably makes sense to disable dumping arguments by default.

[GrahamCampbell]

for Laravel you can use something like

That only works if you dump all your code in your application, but does not work if you have a heavily componentized system.

[GrahamCampbell]

It probably makes sense to disable dumping arguments by default.

Agreed.

[jonasdt]

That only works if you dump all your code in your application, but does not work if you have a heavily componentized system.

If you don't have a common namespace, then you can do something like

$handler->setApplicationNamespaces(['Component1\\', 'Component2\\', 'Component3\\', ...]);

[jonasdt]

Instead of disabling dumping of arguments entirely, we can also cut all internals of the dumped objects (i.e. only show the classname) by default.

@patroniton and @pelim
Can you try my pull request #402? You can include the following lines in your composer.json file, and then run composer update

    "repositories": [{
        "type": "vcs",
        "url": "https://github.com/jonasdt/whoops"
    }],
    "require": {
        "filp/whoops": "dev-cut-internals"
    },

I've tried it for some of my Laravel projects and performance is fine.

[rossbearman]

@jonasdt, your later pull request, #404, makes a dramatic improvement for me, using Whoops in Laravel 5.2. The average load time for the Whoops handler has gone from hovering at around the one minute mark to less than a second.

Without this change Whoops 2 is unusable for me and Whoops 1 doesn't work with PHP 7, so thanks for resolving that.

[denis-sokolov]

Closed via #404. Will release soon.

@rossbearman, thank you for testing it.

[vaites]

I had this problem using PHP-FPM on Mac OS X, but works well with mod_php. Don't know if is caused by my configuration but switching to mod_php on my work machine solved the problem.

[staabm]

please provide a blackfire (or similar) profiling result in case you are running out of memory/time

[vaites]

@staabm, sorry for the delay. I was using a compiled version of PHP on Mac OS X 10.12. I had some strange segfaults so I discarded this installation method in favor of Homebrew and the problem dissapeared. Don't know what was the problem, but I think that maybe is related with those segfaults.

Anyway, I tried to get some profiling but I can't because of the segfaults.