[TYPO3-dev] Are performance improvements part of maintaince releases?

Rupert Germann rupi at gmx.li
Wed Jun 24 12:47:13 CEST 2009


hi,

I read quite often words like "might, could, would, possibly..." in this
discussion. All nice theoretical arguments but they don't really fit the
current case(s).

let's get back to the facts:
In http://bugs.typo3.org/view.php?id=11358 Vladimir suggests to add an
internal cache to function getPage_noCheck() in class t3lib_page.
(This cache exists only during a single page request and will be
re-initialized on each click)

OK, good idea, but what is this function doing and where is it called?

I open class.t3lib_page.php in an editor and add this line at the very
beginning of function getPage_noCheck($uid)

debug(array($uid,t3lib_div::debug_trail()));

After hitting clear-all-caches in the Backend I reload a FrontEnd page with
some plugins on it that produce a bunch of typolinks.
 
The debug window pops up and tells me that this function was called 72 times
with the same value for $uid and that it was called by tslib_cObj->typoLink
which was called by tslib_pibase->pi_linkTP and so on.

The parameter $uid is used in a database query to find out if the target
page for a typolink is visible. This query contains also a call to
$this->deleteClause which simply adds " AND pages.deleted=0" to the query.

In case the page exists and it is not deleted the returned database row will
be merged with a version overlay and/or a language overlay if needed. 

We already know that the $uid parameter in the query does not change during
all function calls. Since all this happens during one single request we can
also be _shure_ that the "deleted" state of the page will not change during
this request.

At this point we are shure that we are doing 72 identical db requests.

What about the version and language overlays? Is it possible that these
values change during one request?

function getPageOverlay():
in this case getPageOverlay() is called without a language parameter, means
it will always use the language value that is set by function
tslib_fe->settingLanguage(). This function is called only once during a
FrontEnd request and it is therefore not possible that the language value
which is used by function getPageOverlay() changes during this request.

agree?

function versionOL():
versionOL() is called with only the db-row and the tablename as parameters
so the first thing it looks on is $this->versioningPreview. 
$this->sys_page->versioningPreview (in class tslib_fe) is first set in
tslib_fe->fetch_the_id(). Later in this function a call to
getPageAndRootlineWithDomain() calls also function getPageAndRootline()
which can set versioningPreview when a workspace is detected.
But all this stuff is triggered by fetch_the_id() which is only called once
per request. 
That means: if it is called multiple times with the same pageID the result
of function versionOL() can not change during one request. 

Ok, back to function getPage_noCheck(). Until now we have found no
possibility that can prevent this function from delivering identical
answers when called with the same $uid parameter.

Is this function used elsewhere?
A fulltext search through the source shows that getPage_noCheck() is used 3
times in class tslib_content. Once in function typolink() and 2 times in
function FORM(). When rendering forms getPage_noCheck() is called to make
sure that the redirect page is actually visible. FORM() is called once for
each form on the page and if the redirect page for each form is different
it will not benefit from caching.  


So how can this fail? how can this make TYPO3 unstable?

That's why I like technical systems: Their behaviour is predictable! ;-)

greets
Rupert






More information about the TYPO3-dev mailing list