Optimizing Page object calls, SQL and Auto Join

[MSP01]

This question relates to optimizing Page object, fields amount and SQL calls, and Auto Join option. In short I need to understand how ProcessWire handles next events:

1. I have a template, which calls for example $page->something->title and this is used for example 2 times in code like if simply ($page->something->title) echo $page->something->title; etc. The field "title" has not the Auto Join option enabled. Is this information loaded in $page object initially or will this fire 2 separate but similar SQL calls to load title, even in same that page and template process? 

2. Let's have another example. We have $page loaded and the template has helper functions to get for example some settings value. Now we use this helper function to retrieve value like $pages->get('template=settings')->somesetting. This will fire SQL call I understand? How Auto Join would help with this?

3. Will enabling Auto Join on fields cause some performance issues outside certain Page object (field that relates to certain template that is used by Page) overall, like when site is loaded first time?

Thank You

@ryan Please can I also have your core developer opinion also here since this has significant impact on how the project code should be structured and this could help many thanks!

[dragan]

@MSP01

I'm no expert on PW's auto join, but re: 2.) I think PW will definitely fire SQL behind the scenes each time you use such a helper function. What you could do instead, is maybe create your own $config vars. That's a perfect use for global settings, e.g. image resize options, or define your own custom paths/URLs etc.

[MSP01]

I did some tests (for example made 50 extra calls with variations in a loop) with Tracy debugger on question 2) but had no effect on PDO or Select queries in Tracy, which made me wonder. I don't have much knowledge about PDO layer but I guess its caching queries somehow. 

[WillyC]

@MSP01

1.. pw cachis any.thing it load, so no.many how times u.cal $page->feld or $page->parent->smoga or $page->feld->bilpa --- it load feld or smoga or bilpa 1 time....... if autojoinin  for.feld smoga or bilpa then it load it with th 1 queery that loader page 

2) yes 1 sql to loader template=settings page and 1 sql to loader somesetting. ifs somesetting.feld is autojoinin then 1 sql for both. if u.cal eithers template=settings page agains or somesetting agains then alredy loadeded so no xtra sql unless u $pages->uncacheAll() whch clearys it all

3- may be. autojoinin can makes littel small faster but at cost of memry .use autojoinin only for.felds that u accessor on.evry load of $page. title good  one to be.autojoinin ......most othrs not;;; body or images and most betters not autojoinin

[MSP01]

@WillyC

Thanks WillyC.

Does this meaning that PW caches queries (like field is loaded once although it is called multiple times within same page process) even if there is no ProCache or similar in use? Or is this a PDO layer feature?

It would be nice if developer docs could cover a bit deeper the performance aspects and best practices relating to queries, PW basic caching out of the box, sql&PDO etc. since it is so easy to use lots of fields that drawn the performance in some point.

@ryan

[LostKobrakai]

9 minutes ago, MSP01 said:

Does this meaning that PW caches queries (like field is loaded once although it is called multiple times within same page process) even if there is no ProCache or similar in use? Or is this a PDO layer feature?

It's neither. Pages are objects and field values are stored within that object. If the field was not yet accessed it will be loaded and stored. After that it'll directly use the value in memory. Most often people wouldn't even refer to that as caching as it's still just stored in memory and for the current request only – but tech. it is a form of caching.