Hi Oleku,

There are a few things going on in that commit. Using a []byte rather than
a bytes.Buffer removes a layer of indirect and also implies:

- Removing function calls to Write() and WriteByte(), those are now array
index based accesses.
- Not writing some data. The magic byte is only set when a new []byte is
made and some bytes were always zeros, so the new code just skips that.
This also
avoids copying a few bytes on every command sent.
- When creating a new []byte, its capacity is set to avoid growing it for
the current key and extras.
- Using PutUintxx rather than binary.Write. This avoids the creation of a
interface{} and a type switch inside binary.Write(). Also, the methods are
locally to the package, to avoid looking up binary.BigEndian on every call
(it's a var, not a const).

All those things add up and give the benchmarked differences in execution
time and memory usage.

On Thursday, October 31, 2013 2:08:40 PM UTC+1, Oleku Konko wrote:

Is there any reason why bytes greatly affect performance ? looking at
your comment from

This reduces memory usage significantly, in some cases even by 50% while
also giving a ~10% performance improvement.<https://github.com/rainycape/gomemcache/commit/57f7621a90d011a646e56f0e93339afb25f8e485>

On Wednesday, October 30, 2013 5:23:57 PM UTC+1, Alberto García Hierro

After porting a site which heavily uses memcache from Python to Go I
noticed a lot of logged errors due to timeouts when communicating with
memcache. After a bit of profiling, I found that the library we were using (
https://github.com/bradfitz/gomemcache) didn't have very good
performance, so I decided to fork and improve it, in order to get better
cache response times and lower memory usage.

I've just uploaded the result at https://github.com/rainycape/gomemcache.
We're not using it in production yet, but we'll start doing so really soon
(probably tomorrow). Since everyone loves numbers, i'm attaching a
performance comparison between the old implementation and the new one to
this email.


benchmark old ns/op new ns/op delta
BenchmarkSetGet 214443 175154 -18.32%
BenchmarkSetGetLarge 262164 196155 -25.18%
BenchmarkConcurrentSetGetSmall10_100 82561221 62172865 -24.69%
BenchmarkConcurrentSetGetLarge10_100 96067285 74113235 -22.85%
BenchmarkConcurrentSetGetSmall20_100 152834658 116654143 -23.67%
BenchmarkConcurrentSetGetLarge20_100 202574186 144950678 -28.45%

benchmark old MB/s new MB/s speedup
BenchmarkSetGet 0.03 0.03 1.00x
BenchmarkSetGetLarge 4.82 6.44 1.34x
BenchmarkConcurrentSetGetSmall10_100 0.07 0.10 1.43x
BenchmarkConcurrentSetGetLarge10_100 13.16 17.05 1.30x
BenchmarkConcurrentSetGetSmall20_100 0.08 0.10 1.25x
BenchmarkConcurrentSetGetLarge20_100 12.48 17.44 1.40x

benchmark old allocs new allocs delta
BenchmarkSetGet 18 6 -66.67%
BenchmarkSetGetLarge 19 6 -68.42%
BenchmarkConcurrentSetGetSmall10_100 58469 6268 -89.28%
BenchmarkConcurrentSetGetLarge10_100 59848 6277 -89.51%
BenchmarkConcurrentSetGetSmall20_100 117177 12663 -89.19%
BenchmarkConcurrentSetGetLarge20_100 120173 12686 -89.44%

benchmark old bytes new bytes delta
BenchmarkSetGet 2479 170 -93.14%
BenchmarkSetGetLarge 7537 1184 -84.29%
BenchmarkConcurrentSetGetSmall10_100 3101520 203867 -93.43%
BenchmarkConcurrentSetGetLarge10_100 8330341 1211143 -85.46%
BenchmarkConcurrentSetGetSmall20_100 6318072 421952 -93.32%
BenchmarkConcurrentSetGetLarge20_100 16884200 2437906 -85.56%
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 9 of 12 | next ›
Discussion Overview
groupgolang-nuts @
postedOct 30, '13 at 4:24p
activeOct 31, '13 at 9:28p



site design / logo © 2022 Grokbase