Allow lru_cache to accept any type for which equality is defined

Allow lru_cache to accept any type for which equality is defined

[sougou, 2012-09-04 17:49:36]

This sounds like a good idea. However, this code is used in a critical
section of vtocc. So, we'll need to rerun our benchmarks to make sure it
doesn't have any adverse effect.
We're also in the middle of some big changes. I'll try to squeeze in time
for this soon.


On Mon, Sep 3, 2012 at 4:55 PM, <ghais.issa@gmail.com> wrote:

>
https://codereview.appspot.**com/6501079/<https://codereview.appspot.com/6501...
>

[sougou, 2012-09-09 20:23:16]

I just ran a benchmark that tests peak throughput, and I see a drop of
about 4-500qps when I use the interface{} based approach. It's most likely
because of lock contention because every query served by vtocc goes through
that path of code. So, any delay there affects overall throughput.
As I said before, this is a good idea. I'll try to think of some way to
accommodate it without sacrificing performance.


On Tue, Sep 4, 2012 at 10:49 AM, Sugu Sougoumarane <sougou@google.com>wrote:

> This sounds like a good idea. However, this code is used in a critical
> section of vtocc. So, we'll need to rerun our benchmarks to make sure it
> doesn't have any adverse effect.
> We're also in the middle of some big changes. I'll try to squeeze in time
> for this soon.
>
>
> On Mon, Sep 3, 2012 at 4:55 PM, <ghais.issa@gmail.com> wrote:
>
>>
https://codereview.appspot.**com/6501079/<https://codereview.appspot.com/6501...
>>
>
>

[ghais, 2012-09-10 14:10:12]

Thanks sougou. 
Are these benchmarks in Vitess? If so I can try to think of a way to keep the
performance at the same level as well.

On 2012/09/09 20:23:16, sougou wrote:
> I just ran a benchmark that tests peak throughput, and I see a drop of
> about 4-500qps when I use the interface{} based approach. It's most likely
> because of lock contention because every query served by vtocc goes through
> that path of code. So, any delay there affects overall throughput.
> As I said before, this is a good idea. I'll try to think of some way to
> accommodate it without sacrificing performance.
> 
> 
> On Tue, Sep 4, 2012 at 10:49 AM, Sugu Sougoumarane <sougou@google.com>wrote:
> 
> > This sounds like a good idea. However, this code is used in a critical
> > section of vtocc. So, we'll need to rerun our benchmarks to make sure it
> > doesn't have any adverse effect.
> > We're also in the middle of some big changes. I'll try to squeeze in time
> > for this soon.
> >
> >
> > On Mon, Sep 3, 2012 at 4:55 PM, <mailto:ghais.issa@gmail.com> wrote:
> >
> >>
>
https://codereview.appspot.**com/6501079/%3Chttps://codereview.appspot.com/65...>
> >>
> >
> >

[sougou, 2012-09-10 17:59:59]

These are custom benchmarks. They use internal data and involve multiple
machines.
But it's a good idea to publish something everyone can use. I'll keep this
in mind.


On Mon, Sep 10, 2012 at 7:10 AM, <ghais.issa@gmail.com> wrote:

> Thanks sougou.
> Are these benchmarks in Vitess? If so I can try to think of a way to
> keep the performance at the same level as well.
>
>
> On 2012/09/09 20:23:16, sougou wrote:
>
>> I just ran a benchmark that tests peak throughput, and I see a drop of
>> about 4-500qps when I use the interface{} based approach. It's most
>>
> likely
>
>> because of lock contention because every query served by vtocc goes
>>
> through
>
>> that path of code. So, any delay there affects overall throughput.
>> As I said before, this is a good idea. I'll try to think of some way
>>
> to
>
>> accommodate it without sacrificing performance.
>>
>
>
>  On Tue, Sep 4, 2012 at 10:49 AM, Sugu Sougoumarane
>>
> <sougou@google.com>wrote:
>
>  > This sounds like a good idea. However, this code is used in a
>>
> critical
>
>> > section of vtocc. So, we'll need to rerun our benchmarks to make
>>
> sure it
>
>> > doesn't have any adverse effect.
>> > We're also in the middle of some big changes. I'll try to squeeze in
>>
> time
>
>> > for this soon.
>> >
>> >
>> > On Mon, Sep 3, 2012 at 4:55 PM, <mailto:ghais.issa@gmail.com> wrote:
>> >
>> >>
>>
>
> https://codereview.appspot.****com/6501079/%3Chttps://coderev**
> iew.appspot.com/6501079/ <http://codereview.appspot.com/6501079/>>
>
>> >>
>> >
>> >
>>
>
>
>
>
https://codereview.appspot.**com/6501079/<https://codereview.appspot.com/6501...
>