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

[Ingmar Schlecht]

Hi Rupi,

actually, I really like the fact that you took the time to analyse this
in so much detail, and I also believe that this should be a necessity in
all cases when we commit something more than a bugfix to a stable branch.

One comment though, regarding "the $uid parameter in the query does not
change during all function calls". Sure, the UID parameter always refers
to the same page. However, the contents of the page record could change
during that time, e.g. caused by frontend editing.

However, given the fact that you also analysed where exactly this
function was called and all cases seem to be uncritical, I think that
risk is small enough to be disregarded.

So, thanks a lot for the work, Rupi!

cheers
Ingmar


Rupert Germann schrieb:
> 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
> 
>