The only "non-essential" processing that has been mentioned is parsing and normalization of the records returned by the DB.
One can already skip this by specifying an alterante processor function db(...).select(processor=lambda rows,fields,colnames,blob_decode: ....) where processor acts like the parse function defined in dal BaseAdapter. Anyway, delaying the parsing and making it lazy has not performance advantage. If you retrieve N records it is because you plan to do something with all them. If you parse them at retrieve time you are guaranteed to do it once. If you do it lazily, you make the select faster but you risk of parsing them more than once later thus in incurring in an overall performance penalty. The only think that we can do to speed the dal is to do avoid re-executing the define-table. We are working on this. One option would be to have the define table in a module (not a model) which is executed only once and the use the new recorrect method to recycle an existing db object with all its table definitions. this will break migrations and it is still very experimental. Is there something else we can in your opinion improve? Massimo On Tuesday, 26 June 2012 12:05:00 UTC-5, pbreit wrote: > > Massimo, any ideas on DAL performance? I wonder if it would make sense to > have some flags to skip some of the non-essential processing? --