- Issue created by @weseze
- 🇧🇪Belgium weseze
I did some more digging and found the issue is the "webform_library_info_build()".
This function loads all webform, checks them for custom CSS/JS and adds those as a library if needed.The website where we noticed the issue has 1000+ webforms. So trying to load them all leads to 200Mb of memory usage.
I tried changing the code to load them 1-by-1 and clear the static entity caching between each, but this didn't help. The memory usage stayed the same. I thought this would have been a quick and easy "fix"... :(
The better solution would be to split the code in 2 pieces:
1/ general CSS/JSS assets need to be added once in a "shared" library for all webforms
2/ only webforms that have specific CSS/JSS assets need to be loaded: this could still be an issue if there are many: not sure how to address that... - First commit to issue fork.
- 🇬🇧United Kingdom catch
The issue here is loading every webform and then looping over them to check if they have css or javascript.
Config entities support entity queries, so it's possible to pre-filter with an entity query. For me this reduced the time taken for this hook from five seconds to about 230ms - Merge request !656Only load webforms with css or javascript specified when building library definitions. → (Open) created by catch
- 🇬🇧United Kingdom catch
Double checked and ::exists() definitely isn't an option here - it results in loading all the webforms in, so I think the
<> ''logic is correct here. - 🇺🇸United States jrockowitz Brooklyn, NY
The problem and solution makes a lot of sense to me. I am good with it
- 🇨🇦Canada Liam Morland Ontario, CA 🇨🇦
There is an unresolved thread; @catch, @heddn