Fix unneeded repetitive filesystem access / checks (e.g. 10,000 in category view) causing performance issue in custom fields feature

[ggppdk]

Pull Request for Issue #17889

This should fix a considerable part of the performance problem reported in #17889

e.g. 25% or 50% or 75% (please note that i have not tested the performance improvement)

Also the above performance improvement is when having --zero-- textareas / editor fields, since these also include a different performance issue which is that of triggering content plugins, in which case you have performance that depends on slow content plugins !!!

Summary of Changes

If you have 10 or more fields per record (e.g. per article)

Then the layouts of fields are checked several thousands of times (in category view) if they exist
and a few hundrends of times in single record view

With this PR every layou is checked only once

Testing Instructions

Custom fields display in frontend works as before

Expected result

The layouts of fields are checked only once if they exist

Actual result

The layouts of fields are checked several thousands of time if they exist

Documentation Changes Required

None

[Hackwar]

Can you split this into 2 lines? I REALLY dislike assignments in return- or if-statements.

[Hackwar]

I have tested this item ✅ successfully on a88108d

I have tested this successfully, however please split up the assignment to the cache and the return statement. For a customer of mine, this was a gigantic speed improvement.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/17893.}

[Hackwar]

I have tested this item ✅ successfully on 6d59695

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/17893.}

[HLeithner]

I have tested this item ✅ successfully on 6d59695

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/17893.}

[ghost]

RTC after two successful tests.

[Hackwar]

Thank you!