Feature request: ACF performance boost get_field()

get_fields performance was fixed quite a while ago. It preforms as fast as get_post_meta now.

Bill Erickson was probably the loudest about this, https://www.billerickson.net/advanced-custom-fields-frontend-dependency/ See the update at the top of his post.

@grahammtbr Thanks. found this one as well, forgot to update this thread.

Now it’s only the issue of slow wp-admin side once having a lot of custom fields.

Hello,

This is an interesting topic. I’ve already took a deep dive into get_field() function to take a look at how it works, and also, how to improve it. I also managed to pull out a proof of concept solution to avoid a second DB call in it: https://twitter.com/hwkfr/status/1108079443422179328

As @grahammtbr said, ACF drastically optimized DB calls over the time, and specifically since version 5.7.10 (January 2019) with the introduction of local storage & rework of cache method. However, there is still one last thing that could (and should) be optimized: the dual post metas my_field & _my_field that are saved/loaded by ACF. (Note: Elliot already confirmed he’s working on this).

In fact, get_field() still does 2 DB calls (if you’re using Json/PHP Sync. 3 without it):
– One to retrieve the reference _my_field => field_123456789
– One to retrieve the value my_field => 2019-11-29

This behavior is mandatory for the moment, because the reference key is used to retrieve field configuration, and specifically the formatted ouput value. In this example, if we’ve set format value to dd/mm/YYYY, my_field value will render 29/11/2019 and not 2019-11-29.

This is why get_post_meta('my_field') is still faster than get_field('my_field'). However, if you use get_post_meta('my_field'), you lose a great part of ACF: formatting ouput values.

There’s a possible hack, which is part of the proof of concept I submitted. If you only use field_key instead of field_name in your get_field() calls, then you can stick to 1 DB call (you also have to add some hooks). However: This means you’ll have to let user customize field_123456789 (because field_123456789 is not really readable), and also, you should make it absolutely unique.

This is why the subject is tricky. ACF let you have multiple fields with the same name (because the reference is the unique key). This flexibility is a really nice feature of ACF.

Now @alriksson, you mentioned an interesting ‘Get field alternative’ code that I haven’t read before. I must say his trick is really smart. His post is about get_fields() tho, which retrieve all fields, but still act as get_field() because references are also retrieved.

I don’t really like the part where you have to set Json path and decode it. But, that made me think about a possible solution to adapt it on get_field() function. I think it is possible to automatically retrieve the correct json configuration without providing it. This solution avoid the second reference DB call which will make get_field() essentially work like get_post_meta() (performance-wise).

I will run some tests, and see what I can make out of it ??

Regards.

@hwk-fr Sounds very interesting! I’m excited and following!!

My concern is wp-admin as well which would be fewer db calls with 1 instead of 2. I have a lot of predefined meta fields. To not give the user control or rooms for mistakes. So instead of putting workload on the user to add 100 fields, I have predefined them in custom fields. So that the user just can insert the other values for each one.

But this comes with a load and slower edit post load. So my question has been:
1. Is the load the same if I let the user add those 150 rows in a repeater instead?
2. How can this be optimized in the backend of the post? Can those fields be lazy-loaded? Or how could they be optimized for performance?

Right now I have 50 rows which have 3 values each meaning 50×3=150 only for one part.

Post edit:
https://tppr.me/Pf2IX
https://tppr.me/U1fAW

Surely WPML do some queries as well. Looking forward!

Hello Rookie,

This is an another problem, I think you’re doing it the wrong way, there should not be 150 get_option() calls to do what you wanna do. It’s more a method problem.

You should join us on Slack https://wpacf.slack.com so maybe I can help you about that. Or submit an another ticket for this problem (pelase add your code snippet too).

Regards.

Do you refer to the query print screen? If so it comes from various plugins. Just shortpixel-image-optimizer throws 70 queries.

Just a short extract of some of the bigger amount of queries:

Component SELECT SHOW UPDATE DELETE INSERT Time
Core	19	2	1	 	 	0.0144
Plugin: acfml	41	 	 	 	 	0.0091
Plugin: shortpixel-image-optimiser	72	 	 	 	 	0.0037
Plugin: wordpress-seo	13	 	 	 	 	0.0030
Plugin: sitepress-multilingual-cms	39	 	 	 	 	0.0026
Plugin: wp-rocket	16	 	 	 	 	0.0023
Plugin: advanced-custom-fields-pro	8	 	 	 	 	0.0014
 	262	3	2	2	2	0.0522

Hey,

I need to take a look at how you add those 100 rows to help you. Please create a new ticket or join us on Slack.

Regards.

How do I sign up to the WPACF slack team channel?

Oh yeah sorry, here is the invitation link: https://join.slack.com/t/wpacf/shared_invite/enQtODQ3OTY0MjY3MTA0LTJjNGUzN2E4ZTcxZWUwZWYyNWY3OTUwYzQzOTMzNDk1MjI3NzMzYjI3ZGYzNGIxN2I1NjM1ZjEzNmE1MGRmNTY

I’ll update the link in the readme ??

@hwk-fr Cheers ??