MyLibrary

Some of the complaints that we hear about MyLibrary is that it is too slow. This has been true because the core modules for the API were too old school OOP, and incorporated “attribute” values which were in reality bulky arrays of data representing the relationship between the object and other objects in the database. Since the MyLibrary modules are essentially an API for doing database IO, the best way to improve efficiency is to improve the efficiency of the data input/output system internal to the modules. This is what I’ve done.

For example, the constructors (new() methods) for the Facet, Term and Resource modules now no longer create term or resource arrays each time they are called which represent the relational integrity between those database entities. Instead, the related_terms(), related_resources() and related_terms() methods (respectively) now do all of the database IO for those method calls. The only downside to this is that you need to make sure you run commit() on your objects at least once before you call these methods so that the database keys are created for the object.

The performance increase seems to be substantial. In one benchmark test that I ran, against a list of 1096 electronic journal resource records, the increase in performance was 84%. Under the old modules, it took a whopping 133 seconds to build this list in HTML. Under the new modules, it took 21 seconds. Granted, this is still a little slow but I was running this test on a slow system. On faster server architectures, the benchmark would be much more significant. The new modules have been uploaded to our CVS repository, and Eric promises to put them out on CPAN very soon. All of the tests were run successfully against the new modules, and they should function as before.

Tags: General Information //