I see, thank you.
RE reducing the capacity, I want to distinguish freeing the memory (1) used
for the slice and (2) referred to by the slice elements. I can easily see
that freeing (1) is hard and not so beneficial, but I can't see why (2)
would be difficult, and the benefit seems potentially m
Reducing a slice's length makes the elements unreachable, but the GC
appears to still treat them as live, based on this snippet:
https://play.golang.org/p/SvsE-nXi-JA
I would have expected the HeapInUse to go down in the second measurement.
Why is that?
I presume that the GC is traversing the
I use the x/net/trace package to trace requests, and I am running into a
panic caused by adding to a trace after it was Finished[1].
Here's the scenario:
- One incoming request leads to 2 parallel requests to backends.
- We return the fastest backend's response to the user and Finish the trace.
You could use json iterator’s Stream type if you prefer to feel better by
having it wrapped in a library. It does the same thing of course. As the name
suggests it can be used to incrementally write the json to a writer if that’s
what you’d like.
https://godoc.org/github.com/json-iterator/go#St
I was curious if reducing the capacity of slice makes that memory available to
be reclaimed?
(1) Reducing capacity using a three-index:
var s = make([]int64, 1e9)
... add data to s, keeping a count ..
s = s[:n:n] // reduce length and capacity to number of items read
(2) Reducing capacity by sl
I maintain the github.com/robfig/cron package, and I have just released v3
using Modules via the branch mechanism (so it's on a v3 branch), but I'm having
some issues.
Here are things that would be ideal:
- When people visit github.com/robfig/cron, I would like them to see the v
We do this exact thing except using closure templates
https://blog.gopheracademy.com/advent-2014/soy-programmable-templates/
--
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
PSA: If anyone uses upx to shrink linux binaries, beware that it will now
produce a binary that segfaults immediately.
On Tuesday, August 16, 2016 at 7:50:22 AM UTC-4, bep wrote:
>
> Congrats! Good stuff!
>
> I wrote the benchmark below to compare two branches in Hugo, but ran a set
> after 1.7
Go 1.6
I haven't tried tip but according to a comment on a related issue
<https://github.com/golang/go/issues/6853#issuecomment-66088642>, it
doesn't sound like this is seen as Go's issue so I wouldn't expect any
changes
$ GOOS=darwin go build -o glock github.co
Does anyone know a way to use upx (or comparable tool) to shrink Go darwin
binaries? (It already works extremely well for linux binaries)
I saw a link to mpress which claims to do the same thing (brew install
mpress), but the source site appears to have gone offline and I can't find
a copy of
10 matches
Mail list logo