On Friday, 26 August 2016 06:02:56 UTC-4, Peng Gao wrote:
>
> I am doing a bench for my map-based cache.
>
> the get implementation is the same
> // Get an item from the cache. Returns the item or nil, and a bool
> indicating
> // whether the key was found.
> func (c *cache) Get(k string) (interface{}, bool) {
> c.mu.RLock()
> // "Inlining" of get and Expired
> item, found := c.items[k]
> if !found {
> c.mu.RUnlock()
> return nil, false
> }
> if item.Expiration > 0 {
> if time.Now().UnixNano() > item.Expiration {
> c.mu.RUnlock()
> return nil, false
> }
> }
> c.mu.RUnlock()
> return item.Object, true
> }
>
BTW, you can simplify the control flow to:
c.mu.RUnlock()
if !found || item.Expiration > 0 && time.Now().UnixNano() > item.Expiration
{
return nil, false
}
return item.Object, true
I assume your map's values are Items, not *Items, otherwise it may not be
safe to release the lock until you have finished looking at the item.
When I do benchmark, there are a lot of runtime.mallogc calls in
> implementation of cache2, which deplay the response.
>
> And I dump the file, i found cache1 has no newobject called between RLock
> and mapaccess2_faststr, but cache2 implementation has a newobject called
> which calls runtime.mallocgc.
>
> Why runtime.newobject is missing in map access ?
>
It looks like the compiler has decided that 'item' escapes and must thus be
heap-allocated, even though that isn't necessary.
Add -gcflags=-m to the compiler flags to make it print its escape analysis
decisions. Perhaps there's a compiler optimization bug to report.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
