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) * 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 ! * XSLT parsing. That's quite consuming (and first for XSLT result list !), caching them will have the greatest effect ! So, on the 3 places on my list, 2 are not a problem of caching, in fact ;-) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08