[TYPO3-mvc] Strange performance problem - a lot of databasequeries

[Lienhart Woitok]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Jochen,

>>> Another point on value objects: since Jochen Rau introduced
>>> translation handling, value objects are persisted without content
>>> (since the argument $rows for insertObject() in Persistence_Backend
>>> was removed but is used to pass the content of a value object into
>>> this function).
>
> That's a regression. Did you file an issue for this?

Not yet, sorry. There are more issues with value objects I wanted to look at before filling bugs about it (see below), but I can of course file one for this now.

>>> I measured performance using TYPO3 time tracking functionality
>>> resulting in something like 800 milliseconds for controller and 1300
>>> milliseconds for persistence before solving this, about 800 ms for
>>> controller, 80 ms for persistence afterwards. There were about 80
>>> objects handled by persistence, the template displayed near to nothing
>>> (missing lazy loading, but that is not the point here).
>>>
>>> I attached a patch that helped me here but I should mention that I'm
>>> neither sure whether this is a solution or just fighting symptoms (I
>>> suspect latter) nor that this is stable. Therefore I did not put it on
>>> forge yet. If you don't use value objects this patch should still help
>>> you.
>
> There are indeed several things to be fixed and optimized. I know that
> there are several patches pending addressing this topic and I am sure
> that we get the things fixed before TYPO3 4.4beta3.
>
> How should we deal with ValueObjects? ATM there is a mechanism that
> tries to avoid duplicates (= ValueObject with the same set of propety
> values) in the database. And ValueObjects are persisted on every hit.
> That's intended but inefficient and should be solved another way.

It is probably a good idea to avoid duplicates, they would only complicate matters as I see it. This works very well for me at the moment (after re-adding that $row argument).

What I don't understand is why it is intended to persist value objects on every page hit. I have not yet found any issues after I disabled this behaviour (by resetting the uid value in _cleanProperties clone of the object, see patch).

The main problem I currently see with value objects is the inconsistency with uids. Some value objects have the uid set, others have not. Thus it is not reliably possible to use == on them. But what is the correct way? Should they have a uid or not? On the one hand, per definition of value object, they should not have an identity, so no uid. On the other hand, we need this uid for referencing to it in the database and to pass a value object for example in URLs. But as soon as they have an uid the comparision problem cannot disappear (if you create a new value object with equal properties but no uid, it should be the same but comparission would not see it that way). Should we introduce a java like equals() method?

Well, enough of that for now.

Kind regards,

Lienhart Woitok
Web-Entwickler

Telefon: +49 (911) 539909 - 0
E-Mail: Lienhart.Woitok at netlogix.de


- --
netlogix GmbH & Co. KG
Systemhaus | Trainingscenter | Medienagentur
Andernacher Straße 53 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: mailto:info at netlogix.de | Internet: http://www.netlogix.de/

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Stefan Buchta, Matthias Schmidt




-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.0.0 (Build 2881)
Charset: Windows-1252

wpUDBQFL6+0KWevMF2ftbKMBCEN1A/4k1TWMnpJ+AnTRzwHdl7ef057Wuood5PMg
x0XnOaVUj8tdJ4Bjin5oVYftIOj/E1hZiyb3ewH87zuNeLAgDJpP5E1uC08qf7Si
HFcPOaiZnaIgWjuSvtH/QwohLdH4g+NXUHHDkHWluadAMv/S77MLYtAYd+0c4lOT
DaG6UjIiHw==
=+Kcp
-----END PGP SIGNATURE-----