[Koha-devel] Restructuring C4

[LAURENT Henri-Damien]

Le 30/03/2011 16:47, Ian Walls a écrit :
> Fellow Developers,
> 
> 
> Last night, I stayed up late running circ/circulation.pl
> <http://circulation.pl> through NYTProf, to get an idea where we may be
> able to optimize circulation for speed.  After much frustration (darn
> session IDs...), I was able to get a report.  The results were... not
> exactly what I expected.
> 
> It seems that much of the time spent running circ/circulation.pl
> <http://circulation.pl> is spent BEGINing the various C4 modules,
> multiple times.  C4::Items, for example, is BEGuN 14 times in the
> execution of circ/circulation.pl <http://circulation.pl>.  More stats:
> 
> C4::Accounts - 8 BEGINs
> C4::Acquisition - 14 BEGINs
> C4::Auth        - 14 BEGINs
> C4::Biblio       - 14 BEGINs
> C4::Branch     - 5 BEGINs
> C4::Circulation - 22 BEGINs
> C4::Context     - 18 BEGINs
> C4::Dates       - 12 BEGINs
> 
> ... and so on.  Even modules like C4::XSLT, C4::SMS, C4::Suggestions,
> and C4::Search::PazPar2 are BEGuN several times, without any calls to
> any of their subroutines.  Some modules, it seems, don't have an END at
> the end...
> 
> I was also able to get a Graphviz file out, showing all the package
> calls (folks may remember my keen interest in such things from
> KohaCon).  Running it through sccmap to detect cycles, I found a very
> long one between several of the modules.  About 8 packages long.
> 
> All this indicate to me that we REALLY need to start thinking about
> imposing some kind of structure on C4.  I'm thinking something with
> two-levels:
> 
> Level 1 :  Calls to the database, other direct interaction with stored data
> Level 2:   Calls to Level 1 functions to manipulate data
> 
> all our scripts would then be modified to call only Level 2, which would
> take care of talking to Level 1.  At the worst, a particular Level 1
> package would be BEGuN as many times as there were Level 2 packages
> BEGuN in the script (and we could certainly do better).  It would
> eliminate all the cycles, as well.
> 
> I can provide access to my report for anyone who needs it, or more
> details about how I obtained it.  Whatever any of you need to keep this
> conversation going.  This is a big deal, in my opinion, and we need to
> start detangling our code before too much long, or we're going to get
> seriously bogged down.
> 
> Cheers,
> 
> 
> -Ian
> 
Thanks Ian for that investigation.
I am really interested in your figures and ways to investigate.
What you are trying to say meets the concern of many of us.
That kind of Begin calls would be a killer for Data Persistence. But It
seems that when you preload the code, things are behaving not so badly.
I tried to launch starman a prod.psgi in order to test the Plack stuff
and it behaved pretty good.

I also proposed that we could use a kind of "Controller" Modules in
order to externalise those CanItemBe.... Can.... this Action be taken...
This often leads to use modules in a strange way : think of Circulation
and reservation for instance. I had proposed to get those subroutines
out of those modules. But it would add to the list of modules we import
at the view level.
In my opinion, the simpler we get, the more powerful and flexible we
will be.
Having simple 'objects' which creates/adds/updates/display/delete and
are searchable with simple APIs, and a way to make use of those objects
no matter the backend (DBI, Storable, YAML) could be achieved... But not
by one company on its own. It would need coordination and cooperation.
Shifting to OO design would imply some overload that maybe not everyone
agrees on... And this would need some Data persistance layer in order to
cope with that.
But yes, there is place and need for a refactoring... that we can
achieve if we all join forces. And if we have a big picture and a kind
of schedule, and also exemples of how things should be done then it
would be much easier for ppl to collaborate.
This won't be achieved in 6 months, maybe not even in a year... But i
think it is worth...
-- 
Henri-Damien LAURENT