[Koha-devel] using CHI directly to use all of it's advantages

[Jared Camins-Esakov]

Paul,

On Fri, Jun 15, 2012 at 5:42 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Le 15/06/2012 11:32, Dobrica Pavlinusic a écrit :
> > I look at memoize as a easy way to find our which parts of our data
> > model should be cached. Once we find contended places, we can remove
> > memoize and implement proper compute for that part of code.
>
>
> quick answer (I'll answer more completely later)
>
> About contended places, I see 3:
>  * systempreferences that call each syspref one by one. Result in 60 SQL
> for each page. It would be better to load all sysprefs in one SQL. The
> patch should be easy to write (we had it at BibLibre, it has been lost
> in limbo between 3.2 and 3.4 iirc)
>

Dobrica said he plans on reimplementing this. It's a showstopper for Plack.
(side note: the Plack-unfriendly hash could easily be replaced by a
Plack-friendly in-process CHI cache, if the consensus were that fastmmap
was a bad idea)


>  * languages_* stuff. I spoke of this with chris_c during the KohaCon12
> hackfest, to know if he understand how this code works. He don't. I
> don't. If anyone understand, he is welcomed, but I think (and chris
> agrees) that the best option should be to drop all this code and
> re-write it from scratch. An acceptable circumvent could be to put in a
> hash those tables that never changes (and user can't change through Koha
> interface anyway). If a new language arise, just fix the hash !
>

This should never have been in the database. Also, there is a 1-1
relationship between almost all the language tables. We should just have
sort of configuration file with that information (maybe in YAML?). Also,
using just one type of language code might be nice.

 * XSLT parsing. That's quite consuming (and first for XSLT result list
> !), caching them will have the greatest effect !
>

It is inefficient, but I have a very surprising performance statistic.
Processing the XSLT for the result list is *not* the most inefficient part
of the results page rendering! Getting authorised value images is the most
inefficient! (I was shocked when I discovered that, too... it makes no
sense at all, but that's what it is)

So, on the 3 places on my list, 2 are not a problem of caching, in fact ;-)


Regards,
Jared

-- 
Jared Camins-Esakov
Bibliographer, C & P Bibliography Services, LLC
(phone) +1 (917) 727-3445
(e-mail) jcamins at cpbibliography.com
(web) http://www.cpbibliography.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120615/922010a7/attachment.htm>