1. 14 Feb, 2017 13 commits
  2. 13 Feb, 2017 24 commits
  3. 12 Feb, 2017 3 commits
    • Alex Brainman's avatar
      path/filepath: add test for directory junction walk · 61bf0d1c
      Alex Brainman authored
      For #10424.
      
      Change-Id: Ie4e87503b0ed04f65d2444652bd1db647d3529f4
      Reviewed-on: https://go-review.googlesource.com/36851Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      61bf0d1c
    • Russ Cox's avatar
      runtime: use two-level list for semaphore address search in semaRoot · 45c6f59e
      Russ Cox authored
      If there are many goroutines contending for two different locks
      and both locks hash to the same semaRoot, the scans to find the
      goroutines for a particular lock can end up being O(n), making
      n lock acquisitions quadratic.
      
      As long as only one actively-used lock hashes to each semaRoot
      there's no problem, since the list operations in that case are O(1).
      But when the second actively-used lock hits the same semaRoot,
      then scans for entries with for a given lock have to scan over the
      entries for the other lock.
      
      Fix this problem by changing the semaRoot to hold only one sudog
      per unique address. In the running example, this drops the length of
      that list from O(n) to 2. Then attach other goroutines waiting on the
      same address to a separate list headed by the sudog in the semaRoot list.
      Those "same address list" operations are still O(1), so now the
      example from above works much better.
      
      There is still an assumption here that in real programs you don't have
      many many goroutines queueing up on many many distinct addresses.
      If we end up with that problem, we can replace the top-level list with
      a treap.
      
      Fixes #17953.
      
      Change-Id: I78c5b1a5053845275ab31686038aa4f6db5720b2
      Reviewed-on: https://go-review.googlesource.com/36792
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      45c6f59e
    • Cezar Sa Espinola's avatar
      image/png: reduce memory allocs encoding images by reusing buffers · 93a18acf
      Cezar Sa Espinola authored
      This change allows greatly reducing memory allocations with a slightly
      performance improvement as well.
      
      Instances of (*png).Encoder can have a optional BufferPool attached to
      them. This allows reusing temporary buffers used when encoding a new
      image. This buffers include instances to zlib.Writer and bufio.Writer.
      
      Also, buffers for current and previous rows are saved in the encoder
      instance and reused as long as their cap() is enough to fit the current
      image row.
      
      A new benchmark was added to demonstrate the performance improvement
      when setting a BufferPool to an Encoder instance:
      
      $ go test -bench BenchmarkEncodeGray -benchmem
      BenchmarkEncodeGray-4                 	    1000	   2349584 ns/op	 130.75 MB/s	  852230 B/op	      32 allocs/op
      BenchmarkEncodeGrayWithBufferPool-4   	    1000	   2241650 ns/op	 137.04 MB/s	     900 B/op	       3 allocs/op
      
      Change-Id: I4488201ae53cb2ad010c68c1e0118ee12beae14e
      Reviewed-on: https://go-review.googlesource.com/34150Reviewed-by: 's avatarNigel Tao <nigeltao@golang.org>
      Run-TryBot: Nigel Tao <nigeltao@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      93a18acf