The file library/adodb/adodb.inc.php contains 3667 lines. Every time it is included in another file, These several thousand lines are included also for processing. This file, in turn, includes other files conditionally. The point of this file is apparently to facilitate connecting to the MySQL database. This functionality is already built into PHP. The file is included by library/sql.inc which is included by library/auth.inc which is included by interface/globals.php and others. I did a survey by logging everytime the code in sql.inc was executed to note how frequently these additional 3667+ lines were being evaluated. From the point of logging in, to finding a patient, to going to the beginning of entering an encounter, the file was included 23 times. This is at least 84,341 lines of code processed by the PHP engine for the simple task of connecting to the database to get to the point of entering a new encounter. An additional problem is the fact that OpenEMR uses frames and each individual frame must be authorized as a separate page.
I am wondering what the advantage of adodb is and if it is worth the huge overhead.
I think you have a good point. What we don’t know is to what degree the extra overhead is significant. I suspect it’s not a big deal (and so for me, fixing this is not a big priority at the moment), but I could be wrong.
I do believe it’s good to funnel all the database access through sql.inc, to facilitate future migration to other databases. However I don’t see much value in using adodb on top of that.
I prefer something like ezsql (http://ezsql.justinvincent.com/) because, although it is another abstraction layer, it isn’t huge and you get two benefits from it: 1) Uniform database access (ie, all database access should be handled through the one api). 2) Because it is an abstraction layer, changing the underlying database is simple, (ie, very little code change and all would be contained in one module). Unfortunately, as it stands now, OpenEMR is married to mysql until all database access is forced to go through a single api (abstraction layer). A benefit of ezsql is that you can use adodb under it if desired it seems fairly stable too. When and if I ever get a good chunk of time I’m going to work or improving the database of the base system in general.