Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Testcase Package for FLOW3 (trying to figure out why adding lots of elements to a repository is ok, but adding them to another object is immensely slower)

branch: master

Fetching latest commit…

Octocat-spinner-32-eaf2f5

Cannot retrieve the latest commit at this time

Octocat-spinner-32 Classes
Octocat-spinner-32 Meta
Octocat-spinner-32 Resources
Octocat-spinner-32 README
README
This is for testing purposes only

Syntax:
=======
./flow3 addalot:setup:createElements $amount_total $group_each $add_b_to_a

What happens:
=============
ElementA has many ElementBs,
ElementB has many ElementCs,
ElementC has many ElementDs,

If $add_b_to_a == 0 then
  - create $amount_total ElementBs, each having 1 ElementC, each having 1 ElementD
  - add all ElementBs to the ElementB Repository
If $add_b_to_a == 1 then
  - create $amount_total/$group_each ElementAs, each having $group_each ElementBs, each having 1 ElementC, each having 1 ElementD 
  - add all ElementAs to the ElementA Repository

Example:
========
Run these two commands
./flow3 addalot:setup:createElements 100 20 0
./flow3 addalot:setup:createElements 100 20 1

The 1st command:
Creates and adds 100 elementBs to the ElementBRepository (and not creating any elementAs)

The 2nd command:
100 ElementBs are created as well but each 20 elementBs a new ElementA is created to which the ElementBs are added. And instead of adding the ElementBs to the ElementB Repository the ElementAs are added to the ElementA Repository. So you get 5 ElementAs with each 20 ElementBs in it.

Problem:
========
You would assume that this isn't such a big difference, it's not a big deal to just add 5 more write and 5 more read db-operations in the second command, and maybe ~ 1/20 more validations, but in fact the second command is more than 25 times slower (on my machine) than the first one (0.21 seconds vs 5,7 seconds for 20 elementBs).
And in cases where you have to add sub*10 properties this multiplies itself so high that for 10 such (more complex) ElementBs it takes already 25 seconds (more than 200 times slower), and I'm talking about a real case, where 25 seconds for 10 elements just isn't acceptable.

Further Analysis:
=================
Using this commands ...
1. ./flow3 addalot:setup:createcards4 20 5 0
2. ./flow3 addalot:setup:createcards4 20 5 1

... and inspecting the profiler output of that execution with kCachegrind I have found out that 
In 1. command TYPO3\FLOW3\Error\Result->mergeProperty() is being called  6480
In 2. command TYPO3\FLOW3\Error\Result->mergeProperty() is being called 79656

I'd say 6480 mergeProperty calls for 20 Elements is quite a big number, but 79656 calls just because we added 4 additional ElementAs + Associations + Validation, that must be wrong, ... right ?
When changing the code so that each ElementB gets 2 ElementCs it even becomes 231576 mergeProperty calls in the second command. So this feels like some recursion bug.
Something went wrong with that request. Please try again.