On Sun, 2008-02-03 at 16:41 +1300, Amos Jeffries wrote: > Alex Rousskov wrote: > > > > Please give an example or two, where the performance would noticeably > > suffer for standard methods. > > There were several switch(e->method) in what I think is the request > processing pathways. I was thinking making that switch into a series of > string comparisons (on image()) would increase the processing ops where > the current index int checks are faster.
I agree that there should not be any string comparisons. That is expensive and would not buy us much. We should either use id() or isGet() and alike. > The biggest possible hit I've seen so far with the enum change is the > store MD5's, they currently use the int value of the enum. I'm not sure > if it would matter making them always use the image() string instead. > They are certainly capable of it, just the side-effects need checking. > src/store_key_md5.cc:120 > src/store_key_md5.cc:139 Extension methods are not cachable, but we need to check whether having the same id() or key() for multiple methods is going to create problems. I doubt it will because all these store entries should remain private. I am fine with keeping method_t exposed if hiding it creates too many problems. Let's just replace the conversion operator with id() and get rid of EXT values, I guess. Thank you, Alex.
