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.
Received on Sat Feb 02 2008 - 22:31:27 MST
This archive was generated by hypermail pre-2.1.9 : Sat Mar 01 2008 - 12:00:09 MST