[TYPO3-dev] typolink generation high parsetime

[Bernd Wilke]

On Fri, 26 Oct 2007 10:36:42 +0200, Popy wrote
with subject "Re: [TYPO3-dev] typolink generation high parsetime":

> 2007/10/26, Steffen Kamper <steffen at sk-typo3.de>:
> >
> >
> > "Popy" <popy.dev at gmail.com> schrieb im Newsbeitrag
> > news:mailman.3454.1193336329.20721.typo3-dev at lists.netfielders.de...
> > > 2007/10/25, Steffen Kamper <steffen at sk-typo3.de>:
> > >
> > >> but still better than 400 single queries.
> > >> What is big, array of 500(0) integers?
> > >
> > > The query wich will return 500 integers (or more...)
> > > I really think that asking only if needed is better, so, if you build
> > > links
> > > pointing to 5 different pages, your cache array will have only 5
> > entries,
> > > with only 5 littles queries...
> >
> > I don't see this as great progress, as we talk about temporary "cache" for
> > one page generation.
> > If 500 links are links to 500 pages, nothing is won, still 500 (*3)
> > queries.
> > If we have the array of integers, it's one! query.
> >
> > >
> > > By the way, if the function t3lib_pageSelect::getPage has a cache, it
> > will
> > > reduce the number of performed queries for typolinks, rootlines, pid
> > > lists,
> > > menus, etc...
> >
> > this is another point ;-)
> >
> > vg  Steffen
> 
> That's why i speak about this kind of cache :)
> It ensure that we'll never do the same request more than once. Sometimes i
> use this kind of query cache in my extension and it works well.
> Ex: 48 queries processed instead of 293 on my forum on cache generation.
> With cache it is a bit less fun, as I have 6 queries performed instead of
> 11.

I think there are differnt possibilities to have links in a page:

a) just some (<10?) links 'hardcoded' in textbody.
b) an extension generates links depending on data-records: (>100 records)
   i) all links go to the same page(s) (e.g. single-display, edit-display
in list-view)
   ii) each link depends on record-data and can point to different pages

a) doesn't need any caching because it is fast anyway
b)i) needs the visibilty-information(s) just one time to use it again and
again: caching per first call will fit optimal (remember to cache both!: is
visible/ is not visible)
b)ii) as every page can be link-target it would be optimal to have
visibility-information for all pages cached in one query


having case b)i) the links will look something like:
index.php?id=123&L=1&tx_myplugin_pi1[uid]=456&tx_myplugin_pi1[cmd]=edit
with differnt values in the plugin-uid-parameter. This could be handled
within the plugin, generating the Url without plugin-paramter and adding it
for every record.

BUT: what if the record-uid builds up the URL in another way? say something
like RealURl where the record-title shows up as url-path, or chash, ...?
at this moment you can't generate the URL by hand in the plugin and a real
caching would be neccessary.

Bernd

-- 
Don't ask what the TYPO3-community can do for you.
Ask what you can do for the TYPO3-community.

http://www.pi-phi.de/t3v4/cheatsheet.html