Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(19)

Issue 6501079: Allow lru_cache to accept any type for which equality is defined

Can't Edit
Can't Publish+Mail
Start Review
Created:
8 years, 9 months ago by ghais
Modified:
6 months, 2 weeks ago
Reviewers:
vitess, sougou
Visibility:
Public.

Description

Allow lru_cache to accept any type for which equality is defined

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+31 lines, -12 lines) Patch
M go/cache/lru_cache.go View 10 chunks +13 lines, -12 lines 0 comments Download
M go/cache/lru_cache_test.go View 2 chunks +18 lines, -0 lines 0 comments Download

Messages

Total messages: 6
ghais
8 years, 9 months ago (2012-09-03 23:48:52 UTC) #1
ghais
8 years, 9 months ago (2012-09-03 23:55:47 UTC) #2
sougou
This sounds like a good idea. However, this code is used in a critical section ...
8 years, 9 months ago (2012-09-04 17:49:36 UTC) #3
sougou
I just ran a benchmark that tests peak throughput, and I see a drop of ...
8 years, 9 months ago (2012-09-09 20:23:16 UTC) #4
ghais
Thanks sougou. Are these benchmarks in Vitess? If so I can try to think of ...
8 years, 9 months ago (2012-09-10 14:10:12 UTC) #5
sougou
8 years, 9 months ago (2012-09-10 17:59:59 UTC) #6
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...
>
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b