[PATCH] Yet another speed-up on RowProxy

[Former user]

(original reporter: ged) Here is another patch to apply on top of current trunk, which grabs another ~20% for the getitem code path for medium and largish queries (didn't test small ones) on top of current trunk (6448).

The patch is kinda ugly, I admit, but worth it in my opinion. Your call. Also, I don't really know what's the impact of a closure in terms of memory.

[Former user]

(original author: ged) ping? did you see this patch at all?

[Mike Bayer]

this one bugs me. its just self.__colfuncs and self.__parent being saved ? did you get it to work with all the resultproxy variants ?

[Former user]

(original author: ged) yes it's just the self.xxx being saved, though the savings are rather impressive. This is a pure speed VS ugliness tradeoff here.

Didn't try it with the ResultProxy variants as I wanted to know what you think about such an ugly hack before investing more time into it. I see no reason why they wouldn't work though (unless they override __getitem__ which I don't think they do.

[Mike Bayer]

the pickled version will likely fail, however. the __setstate__ would need to rebuild that closure. so there's some great ugliness, writing that entire closure twice, unless you want to put it in a sub-function (but then, a function call). We can't have that whole __getitem__ written twice tho.

[Mike Bayer]

im sorta hoping more for the C speedups instead of this one. Can we close ?

[Former user]

(original author: ged) Yes, that seem the most sensible thing to do. Btw: I'm still alive. It's just that my electrical installation is being redone entirely and given the noise and on/off nature of electric supply, I can't concentrate on any decent work.

[Mike Bayer]

Removing milestone: 0.6.xx (automated comment)