Field type Page creates huge object within $page

[mikeuk]

I've been experimenting with field type Page, to add a page within a page (to replicate a block like system).

I encountered some issues rendering the results, and while debugging and displaying the $page->fieldtypePage object I realised it was huge. I mean 1 minute to display huge.

Even though in normal operation, printing out the whole object wouldn't be necessary. However I presume having an object that large must affect site performance.

I won't be using this field type Page any more because I'm a bit of a fanatic for clean code and good performance. But in general, what do you think? Should this be submitted as a bug? If so, what's the correct procedure for that?

[Wanze]

What rendering issues do you mean? The problem is that you cannot measure performance in printing out objects. If objects contain a lot of references to other objects, this may take time to print out. In terms of page types, you have references to other pages and there may be a recursion problem, e.g. print a parent page with references to its children pages, each child page has again a reference to the parent) etc. 

Quote

I won't be using this field type Page any more because I'm a bit of a fanatic for clean code and good performance. But in general, what do you think? Should this be submitted as a bug? If so, what's the correct procedure for that?

The Page field is one main features in ProcessWire, at least for me. It makes the whole system powerful in terms of data modeling. If you want to measure performance, you should do it right, for example with a PHP profiler. Btw I'm also fan of clean code and good performance, that's why I'm working with ProcessWire

Cheers

[mikeuk]

5 minutes ago, Wanze said:

What rendering issues do you mean? The problem is that you cannot measure performance in printing out objects. If objects contain a lot of references to other objects, this may take time to print out. In terms of page types, you have references to other pages and there may be a recursion problem, e.g. print a parent page with references to its children pages, each child page has again a reference to the parent) etc. 

The Page field is one main features in ProcessWire, at least for me. It makes the whole system powerful in terms of data modeling. If you want to measure performance, you should do it right, for example with a PHP profiler. Btw I'm also fan of clean code and good performance, that's why I'm working with ProcessWire

Cheers

Rendering issues were https://processwire.com/talk/topic/15721-displaying-content-of-page-in-page-field-type/

But wouldn't the size of the object affect performance? If printing it takes over 1 minute, doesn't that signify the object is very large, and that still has to be passed to the page?

I was noticing sluggish performance compared to a previous site, though I hadn't gone deeper as there are other non-PW factors I'd have to address first.

 

[Ivan Gretsky]

Not using Page field is almost impossible for complex sites with ProcessWire. I am almost sure though that actual contents of that field gets loaded only when you call it. Would be happy to hear some expert explanation myself to learn more on the topic.

[diogo]

That doesn't sound right. A page field returns a normal page array, just like a $pages->find() call, and how many pages can you possibly have selected in a page field?

2 hours ago, mikeuk said:

I was noticing sluggish performance compared to a previous site, though I hadn't gone deeper as there are other non-PW factors I'd have to address first.

Are you sure this is not caused by something external to PW (e.g. server config, some external library...)?

[mikeuk]

13 minutes ago, diogo said:

That doesn't sound right. A page field returns a normal page array, just like a $pages->find() call, and how many pages can you possibly have selected in a page field?

The $page->fieldtypePage object that I printed was a page with a field type Page attached, which contained a link to one page only (which has 3 fields within it). The printed output of that object was pages long. I see no reason this how PW normally is as I have no modifications to affect it

 

13 minutes ago, diogo said:

Are you sure this is not caused by something external to PW (e.g. server config, some external library...)?

Quite possibly. As I said I wasn't judging it on my own site performance as there are other issues (it's on a preview domain for one). I was more assuming such a large page object could affect performance

 

[Soma]

Some basics when working in OO software. If you print_r() a object (ie page or field), PHP will traverse the object (try to) and load all its references recursively. It unfolds the object which isn't really present in the original object and only loaded or accesses it if you would do call stuff on this object.  This doesn't mean the object contains all the stuff you see printed at that time before you call print_r().

Edit: Oh a page field contains only a reference (by the id) to the page and loads the page object and not even its content unless you call it (except autojoin fields).

[mikeuk]

7 minutes ago, Soma said:

Some basics when working in OO software. If you print_r() a object (ie page or field), PHP will traverse the object (try to) and load all its references recursively. It unfolds the object which isn't really present in the original object and only loaded or accesses it if you would do call stuff on this object.  This doesn't mean the object contains all the stuff you see printed at that time before you call print_r().

Edit: Oh a page field contains only a reference (by the id) to the page and loads the page object and not even its content unless you call it (except autojoin fields).

That's good to know. Is that unfolding to do with OO software? I've never seen anything like this in Drupal, though that is not always considered OO (especially older versions).

[kixe]

For debugging you could use

print_r($page->fieldtypePage->getArray());

 

[adrian]

A little more info from Ryan on why it is appearing to be huge when dumped:

 the _wire reference present in every Wire derived object points to the current ProcessWire (class) instance. Because the ProcessWire class extends Wire, that means it also has a _wire property, and that property in turn points back to the ProcessWire instance. That's not inherently a problem, and it's necessary for access to API variables by all Wire-derived objects. This is one of the means by which we support multiple instances of PW. There is no recursion unless some code tries to follow the protected _wire property of the protected _wire variable.

In addition to the getArray() that kixe mentioned, also check out getIterator() and be sure to try the TracyDebugger module for dumping objects/arrays.

[szabesz]

1 hour ago, adrian said:

be sure to try the TracyDebugger module for dumping objects/arrays.

+1  of course, but if you need something more general, there are other solutions, such as: https://github.com/leeoniya/dump_r.php

highlights from its readme::

• "$depth sets the recursion limit for the dump"
• "Circular reference (recursion) detection and duplicate output is indicated like this for arrays, objects, closures and resources respectively: [*],{*},(*),<*>."