RE: [PEAR-DEV] [MDB2][RFC] drastic refactoring

Hi, I have been playing with the idea of moving MDB2 to a proxy pattern. The idea would be that you have a set of proxy classes: MDB2_Lite MDB2_Full extends MDB2_Lite These proxy classes proxy rdbms api calls to an object instance we will call driver. MDB2_Driver_Lite_mysql extends MDB2_Driver_Lite_Common MDB2_Driver_Full_mysql extends MDB2_Driver_Lite_mysql As you can see this structure makes it easy extend both the proxy and the driver classes. However performance loss is about 10-20% for a benchmark that does simple query+fetch. More surprisingly there was only a difference of about 1,5% between MDB2_Lite and MDB2_Full. This ratio might be possible to increase by removing all of the optional datatype conversion features. I can see about a 5% increase there. Maybe even 10%. Of course I could cut down runtime by reducing features. For example I noticed that by moving seeking from fetchRow performance increased considerably for fetchRow calls. And maybe I will move seeking to a separate method. So basically I found that by cutting features to a pretty bare minimum (for fetching as I was mainly testing that) I was able to get performance in the proxy variant to that of the full featured non proxy variant. But performance gains can't really be the argument for moving to the proxy pattern going by what it costs to implement it. Memory consumption is also not significant in my opinion. The question is what flexibility we are gaining here: It was possible before to create your own custom variant of a given driver by simply extending the old driver and my specifying the new name of that driver in the DSN. What we therefore only really gain is the ability to easily extend the common part of MDB2 and allowing you to add common functionality (and common fallbacks for features you add to customized versions of drivers). I am not sure this is really worth it. If you want you can write a wrapper class to achieve similar results after all. So all in all I don't think I will go with the proxy pattern, but I will re-examime parts of the code to see if features can be separated a bit more (like row seeking in fetchRow()) Regards, Lukas