Very slow server performance when rendering large number of rows and columns - slow blade rendering

I have a client where one of the requirements is to regularly have views containing 100, 200 or sometimes even more rows on the screen at any time.
The database is fairly small and well-indexed, all queries are less than 1ms. The database is not the problem, there are no n+1 queries etc. The problem appears to be related purely to blade components.

Here are some approximate benchmarks in my application:
50 rows = 0.7s
100 rows = 1.3s
200 rows = 2.79s
500 rows = 6.4s

I have extensively googled this and have tried the following:

Laravel Optimizations:

php artisan icons:cache
php artisan route:cache
php artisan config:cache
php artisan view:cache
php artisan filament:cache-components

php artisan icons:cache
php artisan route:cache
php artisan config:cache
php artisan view:cache
php artisan filament:cache-components

PHP/Nginx Optimizations:
I have gzip enabled (although this is irrelevant for this particular issue since that's just for network transfer), opcache enabled, JIT enabled.

I use Clockwork, not debugbar but I have also benchmarked my app with Clockwork turned off and also on production (where there is no clockwork) with similar results.

I ran an xdebug profile for 100 rows (see attached) and can see that 90% of time is spent rendering the blade components. During the page load my CPU on that particular core spikes to 100%. There definitely seems to be something not optimal here, either with FilamentPHP or LiveWire or perhaps Laravel itself (I am leaning towards the latter).

I have tried disabling each column one by one to see if perhaps one column is causing this, but the time seems to be fairly linear... disabling half the columns results in about half of the render time. Interestingly, the actions seem to add quite a lot of time also to the render (even though I only have 4 actions, but again it seems linear).

Has anyone got any ideas for me or is anyone able to render large tables without this huge performance hit? Thanks in advance.

CTOP•2/13/24, 3:28 PM

In my searches I found the following, but none of them really seem to be relevant to me:
https://github.com/laravel/framework/issues/43811
https://github.com/filamentphp/filament/discussions/5654

I noticed in one of the comments dan mentioned

I am wondering if this is still the case or not because I found this article here; https://laravel-news.com/faster-laravel-optimizations which recommends against splitting up components exessively, but it was written in late 2022 so perhaps it is outdated by now.

Tieme•2/13/24, 8:59 PM

What happens if tou do the following https://filamentphp.com/docs/3.x/tables/advanced#deferring-loading

Advanced - Table Builder - Filament

CTOP•2/13/24, 9:05 PM

Yup I gave that a try, it loads the table (without any rows) quickly but simply shifts the main loading time to the ajax call. The overall time taken remains the same

I've been looking into it more and in my table (which doesn't do anything too crazy imo), almost exclusively just TextColumn, there are on average 40 calls per row (approx 10 columns in the row) to the blade compiler. So 50 rows would be 2000 calls... and 500 would of course be 20,000 calls. I'm leaning towards this being the problem but I'm not exactly sure how to solve it.

Maybe I could expand the question out a bit.. does anyone actually have good performance with a high number of rows and columns? and if so how did you do it?

CTOP•2/29/24, 8:11 PM

bump, anyone have any ideas? I'm still trying to improve the performance but I feel like I've hit a brick wall with the limits of filament/livewire

awcodes•2/29/24, 11:22 PM

We’re hoping to improve this with v4. But basically it’s a limitation of livewire since it has to dom dif the html. So the larger the html the longer it is going to take for the diffing to happen. Same thing can happen with Vue or React too.