Performance - createChild vs pageObject

Kirby 3
1

hey folk,
i do need some help/advice, im sure someone can help me out, im stuck. Im building pages with createChild over an custom api. the page-structure is similar to this:

pages:

-tree
– entry1
– entry2
— e1
— e2
— e3
– entry3
– entry4
– … more pages

i do populate the new childs (e1, e2 …) like:

$parentPageObject = $site->find('tree')->find('entry2');

$parentPageObject->createChild([ ---> create subpages like e1, e2 or e3 ])

this works wonderful if the children-count of entry2 is <500 pages. the api call took around 100ms or less to add the new children to the given parent-page.

now. if you have more than 1000 subpages the situation goes wild. now it tooks around 10s to add the child to the page.

the problem seems to be, kirby is not just fetching the page object but also load the complete child-tree… which makes sense in default usage.

$parentPageObject = $site->find('tree')->find('entry2');

in my situation i do just need the reference to the parent page to add the child, no need to check the children hierarchy. at the end, i just need to create a folder to a parent.

unfortunately i was not able to find a solution in the docs for this. my second guess would be to create the child-folder per hand, but maybe you guys have better idea.

im running this in a vagrant machine, on a 2019 mabook pro. i will also do this test on a live system to compare, but maybe someone has an idea how to solve this?

Edit:
It has really todo with the folders child’s count. the ->find() method takes this in count.

-entry
–a
–b
—1
—2
—more than 2000 more
–c
–d

metrics:
->find(entry) = 100ms because the childs just a, b, c, d
->find(b) = 3-5sec

2

I think using

page('tree/entry2')

will be faster at finding the parent page. No idea if that makes a difference with that many subpages.

3

Thanks for the quick input. I think the ->find and also ->createChild func has limitation because of lookups and building files in the page tree. i did different tests with filtering, page() and so on… but at the end the problem is the page-tree count. if is larger than 2000 entires lookups goes nuts.

now. because the pages in my projects are anyways rendered as virtual-pages and i don’t really need pages for editing, i can switch to sqlite integration. i did already some tests.

db with 10’000 entries

  • write new row <50ms
  • filter and render row <300ms

The cool part is though, i had just to swap a small part of code to get this working. i replaced the createChild, to DB:insert. because i need this data just at some situation in the app, i can easy access it now via the DB:: function. will share speedtest as soon as i have switched full to DB.

4

The solution in my case is the fact switching to DB integration. It’s crazy fast and super easy to use.