Thanks for the detailed thoughtful answer!
Statistically you are correct. 95% of Go features are reasonably fast, and
will get 99% job done very fast. But can we call the benchmark on the rest
5% slow part micro benchmarking?
This can easily become an objective discussion based on different
exper
Bigelow & Holmes, the designers of the Go Fonts, are preparing an
update to those fonts. The changes so far are:
• adjusted box/chart/shade/split-integral to align vertically
• adjusted shade characters to align vertically & horizontally (more
or less aesthetically)
• merged the contours of ring o
You have handed json.Unmarshal a non-slice/non-array type.
Try this https://play.golang.org/p/Zl5G_Rkt26
On Thu, 2017-02-02 at 15:15 -0800, Rejoy wrote:
> I 'd like to unmarshal database records into a struct type. I get the
> error "json:
> cannot unmarshal array into Go value of type main..".
You can use io.TeeReader to connect them all. Also to simultaneously
read from one file, encrypt, and write to another file on the fly you
seems to need a bit of concurrency
func (b2h *B2Handler) EncyptandUpload(iv []byte, fileName string,
outputFileName string) {
key := []byte("example key
Insight here feels tenuous.
It is rare that a well-written "real" program would be measurably
influenced by something this small. As it happens, I often write such rare
programs (where a 2x faster math.Log() really might make the whole program
run 1.9x faster). Even as a poster child for it, I thi
I 'd like to unmarshal database records into a struct type. I get the error
"json:
cannot unmarshal array into Go value of type main..".
Working example https://play.golang.org/p/keY-3z7lyA
I can unmarshal the data to []map[String]string, but cannot reference it
using key value pairs in the
I think your on the right track I just can't get this to work. It seem like
I'm missing something simple to do with GOs readers and writters.
func (b2h *B2Handler) EncyptandUpload(iv []byte, fileName string,
outputFileName string) {
key := []byte("example key 1234")
inFile, err := os.Open(fil
Cool! Upgrading to 1.8.rc3 shows great improvement! I wish all problems can
be resolved by upgrading. :) Here is the before and after result.
chris$ go test -bench=.
testing: warning: no tests to run
BenchmarkAssertion-8 2 9.57 ns/op
BenchmarkAssertionOK-8 2 9
Try to construct an io.Pipe maybe
pReader, pWriter := io.Pipe()
writer:= &cipher.StreamWriter{S: stream, W: pWriter}
UploadFile(outputFileName, metadata, pReader)
writer.Write(src)
On 02/02/2017 10:27 PM, Justin C wrote:
I have a encryption function that gives a cipher.StreamWrit
On Thu, Feb 2, 2017 at 1:04 PM, Chris Lu wrote:
>
> I am trying to build a generic distributed map reduce system similar to
> Spark. Without generics, the APIs pass data via interface{}. For example, a
> reducer is written this way:
>
> func sum(x, y interface{}) (interface{}, error) {
>
> ret
What both? What's the alternative?
On Wednesday, February 1, 2017 at 4:07:30 PM UTC-8, Dave Cheney wrote:
>
> I think both are symptomatic of following a Javaesq style of one type per
> file.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To u
Original poster here. Please do not call it micro benchmarking. My real
life use case is this.
I am trying to build a generic distributed map reduce system similar to
Spark. Without generics, the APIs pass data via interface{}. For example, a
reducer is written this way:
func sum(x, y interface{}
Thanks everyone for your input... I tried HowardCShaw's method before
posting, but I went back and experimented more with it and found that the
output was putting all the variables on one line. I separated them all into
separate lines and it works!
What I was doing:
exportVar=`
export var1="Foo
Thanks! I'm sure I'll never forget this experience :)
--
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,
Sorry guys. False alarm. The real issue was that we needed to use
covermode=atomic instead of covermode=count in our CI.
On Thursday, February 2, 2017 at 12:43:09 PM UTC-5, Aaron Wood wrote:
>
> Hi all,
>
> I'm seeing a very strange issue that I'm not quite sure how to fix:
>
> https://github.com
Oh man, it looks like you can't use covermode=count with race
detection? https://github.com/golang/go/issues/12118
On Thursday, February 2, 2017 at 12:43:09 PM UTC-5, Aaron Wood wrote:
>
> Hi all,
>
> I'm seeing a very strange issue that I'm not quite sure how to fix:
>
> https://github.com/mesos
Ah, right. You need to use `-covermode=atomic` if you want it to work with
the race detector, otherwise the coverage profiling itself can cause races.
On Thu, Feb 2, 2017 at 11:49 AM, Aaron Wood wrote:
> Okay, so what's interesting is that the races only show up when I run
> go test -race -cover
Okay, so what's interesting is that the races only show up when I run
go test -race -covermode=count -coverprofile=count_tmp.out
Running either
go test -race
or
go test -race -cover
does not report any races. Does something seem fishy here?
On Thursday, February 2, 2017 at 12:43:09 PM UTC-5, Aaro
I am actually! I didn't realize that reporting on coverage messes with the
output.
Let me run the tests without coverage enabled...
On Thursday, February 2, 2017 at 2:35:11 PM UTC-5, Kale B wrote:
>
> Are you running your test with coverage enabled? The coverage rewriting
> causes the race detec
Are you running your test with coverage enabled? The coverage rewriting
causes the race detector to indicate the wrong lines in the source file.
On Thu, Feb 2, 2017 at 11:33 AM, Aaron Wood wrote:
> I can't unfortunately since it's private right now :( I can show you the
> entire back off source
I can't unfortunately since it's private right now :( I can show you the
entire back off source file here if you'd like, I just can't link you to
anything right now.
On Thursday, February 2, 2017 at 2:29:37 PM UTC-5, James Bardin wrote:
>
> Can you point to the actual source you're using? The fi
Can you point to the actual source you're using? The filenames and line
numbers in the stack traces don't line up with the file you linked
originally.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receivi
I have a encryption function that gives a cipher.StreamWriter
writer := &cipher.StreamWriter{S: stream, W: outFile}
I am trying to upload it to using a library that has a function that is
uploadFile that requires a IO.reader is there a way to pass the writer to
the io.reader so the file i
Also, the tests that trigger this case look like this:
// Verify that the burst notifier both returns correctly and provides the
right data from its channel.
func TestBurstNotifier(t *testing.T) {
tokens := BurstNotifier(5, 5*time.Second, 5*time.Second, make(chan
struct{}))
if reflect.TypeOf(to
==
WARNING: DATA RACE
Read at 0x00641d50 by goroutine 8:
mesos-go/backoff.Notifier.func1()
mesos-go/backoff/_test/_obj_test/backoff.go:80 +0x55
Previous write at 0x00641d50 by goroutine 7:
mesos-go/backoff.Notifier.func1()
mesos-go/backoff/_test/_obj_test/ba
Making the gap smaller means making the compiler dumber. And I disagree
with you about microbenchmarks. There is a difference between benchmarks
and microbenchmarks and using the latter as the primary means of evaluating
performance is plain wrong. Nothing wrong with artificial benchmarks in
itself
The compiler field hasn't so far reached a state of sophistication in
handling microbenchmarks like the human mind does handle them. Until that
state is reached in compiler technology, it is natural for people to keep
using microbenchmarks as one of the primary performance indicators.
The obser
Can you post the actual output from the race detector?
On Thursday, February 2, 2017 at 12:43:09 PM UTC-5, Aaron Wood wrote:
>
> Hi all,
>
> I'm seeing a very strange issue that I'm not quite sure how to fix:
>
> https://github.com/mesos/mesos-go/blob/next/backoff/backoff.go#L25
> https://github.
Ben, you are correct the dial thing, not sure how that ended up commented.
Anyway, I've removed the custom dial (and tried with the timeout enabled as
well), it did increase r/s a lil bit (5%-10% or so) but it increased the
amounts of timeouts on the remote urls as well.
El jueves, 2 de febrero
The point is, that (as repeatedly pointed out) microbenchmarks just, in
general, don't tell you anything really useful, as any effects you measure
could be due to anything ranging from random noise, over compiler
optimizations to code-alignments. Avoiding type assertions based on
anything contained
HI!
Some updates here, again!
Down the road, i realized my benchmarks where not so correct,
kind of erratic with sometimes huge improvements,
sometimes minor improvements.
I got this sorted out, and found the root of evil to be
`template.HTMLEscapeString`
So i worked this out, and now i m ver
Hi all,
I'm seeing a very strange issue that I'm not quite sure how to fix:
https://github.com/mesos/mesos-go/blob/next/backoff/backoff.go#L25
https://github.com/mesos/mesos-go/blob/next/backoff/backoff.go#L80
This causes a data race, and of course we only see it when running on a
beefy server
First things I notice are that you're overriding the default dialer with
one that doesn't timeout, and you've commented out ReadTimeout in the
client. Both of those could indefinitely hold up client connections
regardless of the DoTimeout call, which just ensures that the Do function
returns be
You can set environment variables in an exec.Cmd:
https://golang.org/pkg/os/exec/#Cmd
% cat example.sh
#!/usr/bin/env bash
echo "The password is $password."
% export password=old_password
% bash example.sh
The password is old_password.
% cat example.go
package main
import (
"fmt"
"os"
"os/ex
I don't think you can do what you want to do, precisely.
But, I do think you can solve your problem!
Instead of actually writing to your environment in the Go code (which can
only be seen by *child* processes *of the Go program*!), just print to
stdout.
That is, instead of os.Setenv("MyPass","
this :
http://craigwickesser.com/2015/02/golang-cmd-with-custom-environment/ ?
On Thursday, February 2, 2017 at 5:23:49 PM UTC+1, Rich wrote:
>
> Hi All,
>
> My dev team did a very bad thing and issued lots of scripts that they
> wrote source a file that is in clear text which contains username
Thanks for the answer.
Yes, it seems to be blocking, I just fixed it with:
http://blog.sgmansfield.com/2016/01/the-hidden-dangers-of-default-rand/
After that change my code is working a lil bit better but still I see a ton
of timeouts + high latency on responses. Maybe the code is locking on
a
Hi All,
My dev team did a very bad thing and issued lots of scripts that they wrote
source a file that is in clear text which contains usernames / passwords
etc. Without having to re-write a ton of existing bash scripts, I wanted
to use Go and have that set the usernames / passwords and introd
A large difference between an implementable highly-optimized run-time
performance of feature X and the physically implemented run-time
performance of feature X causes programmers to avoid X.
On Thursday, February 2, 2017 at 3:32:16 PM UTC+1, Marvin Renich wrote:
>
> * Marvin Renich > [170202 09:
Yes, it is.
As far as I know, everybody does it and/or expects you to. Unless you have
some specific reason not to.
On Thursday, February 2, 2017 at 5:31:32 AM UTC-5, adrian...@hushmail.com
wrote:
>
> Gophers,
>
> Is it idiomatic to add $GOPTAH/bin to $PATH in order access a Go
> executable
BenchmarkAssertion-4 3 4.08 ns/op
BenchmarkAssertionOK-4 5 3.03 ns/op
BenchmarkBare-4 5 3.01 ns/op
BenchmarkIface-4 300055.1 ns/op
BenchmarkReflect-4 112.8 ns/op
CPU: Intel(R) Core(TM) i5 CPU
Ahh fantastic thanks a lot!
tors 2 feb. 2017 kl 15:11 skrev :
> Here is a playground link: https://play.golang.org/p/_wJEBd1L9x
>
> ABStuff string `xml:",innerxml"`
>
> You can capture the innerxml with an appropriate tag; you can also, as my
> third example in the above link demonstrates, captur
* Marvin Renich [170202 09:22]:
>
> BenchmarkIface is testing the wrong thing; the value is swamped by the
> implicit conversion of d (type T) to the function argument of type I.
Or, maybe it is testing the correct thing. That is the problem with
microbenchmarking. Try benchmarking your actual
* T L [170202 04:20]:
>
>
> On Thursday, February 2, 2017 at 4:58:32 PM UTC+8, Axel Wagner wrote:
> >
> > Hi,
> >
> > I can not really reproduce your results. I rewrote your code to use the
> > builtin benchmarking: http://sprunge.us/IfQc
> > Giving, on my laptop:
> >
> > BenchmarkAssertion-4
Here is a playground link: https://play.golang.org/p/_wJEBd1L9x
ABStuff string `xml:",innerxml"`
You can capture the innerxml with an appropriate tag; you can also, as my
third example in the above link demonstrates, capture multiple repeated
tags like that to a list of values. If, as I think y
Il giorno giovedì 2 febbraio 2017 11:31:32 UTC+1, adrian...@hushmail.com ha
scritto:
>
> Gophers,
>
> Is it idiomatic to add $GOPTAH/bin to $PATH in order access a Go
> executable across my filesystem?
>
>
On my system I have set $GOBIN to ~/.local/bin and added ~/.local/bin to
$PATH
Manlio
I have xml that looks like this:
sadasd
gfdfg
...
...
Where a and be can appear in any order and this order needs to be preserved.
I have managed to Marshal xml decently using a struct such as:
type Holder {
A A
B A
}
type A string
type B string
using a MarshalXML method on the
Thanks for the insights.
Am Donnerstag, 12. Januar 2017 21:02:21 UTC+1 schrieb Dave Cheney:
>
> If you had this
>
> type I interface { ... }
> type T struct {
> sync.Mutex
> }
> var t T
> var i I = t
>
> This is a mistake because a *copy* of the contents of t is assigned to i.
>
> Every assig
is there a paper to read that introduces and explains benchmark pitfalls
and BP for naive developers ?
there are papers out there which talks about go bench, it is sparse and
often they pretext an obvious
bad code to introduce the reader to the benchmarks go tooling .
Which is good, don't take
Yes
--
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.
On Thursday, February 2, 2017 at 6:01:19 PM UTC+8, T L wrote:
>
> I found that it is much faster if the dynamic values are pointers instead
> of non-pointer.
>
By looking the code of function assertE2T in runtime/iface.go,
ot looks memmove(to, from unsafe.Pointer, n uintptr) is slow for values
I want to re-emphasize that all of these are micro-benchmarks. They say
nothing useful at all, as proven by this thread; in some circumstances, the
added cost may be significant, in others it isn't. The same rule that has
been repeated lots of times on this list still applies: Write your program
to
Don’t know if I would call it idiomatic, but (IMO) it makes things easier for
a few use cases so I’ve also added $GOPATH/bin to my $PATH :)
Sander
On 2 Feb 2017, at 11:31: 32, adrian_le...@hushmail.com wrote:
Gophers,
Is it idiomatic to add $GOPTAH/bin to $PATH in order access a Go executab
Gophers,
Is it idiomatic to add $GOPTAH/bin to $PATH in order access a Go executable
across my filesystem?
Aidy
--
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
I found that it is much faster if the dynamic values are pointers instead
of non-pointer.
package main
import (
"testing"
)
func AssertInt(c *int, d interface{}) {
*c += d.(int)
}
func BenchmarkAssertionInt(b *testing.B) {
count := 0
var t int = 1
d := (interface{})(t)
0.44ns/op is about 2.2.ghz, the compiler has optimised away your
microbenchmark.
--
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...@googleg
On 02/02/2017 09:27, Ian Davis wrote:
On Thu, 2 Feb 2017, at 09:20 AM, T L wrote:
On Thursday, February 2, 2017 at 4:58:32 PM UTC+8, Axel Wagner wrote:
Hi,
I can not really reproduce your results. I rewrote your code to
use the builtin benchmarking: http://sprunge.us/IfQc
Gi
On Thursday, February 2, 2017 at 5:28:26 PM UTC+8, Ian Davis wrote:
>
>
> On Thu, 2 Feb 2017, at 09:20 AM, T L wrote:
>
>
>
> On Thursday, February 2, 2017 at 4:58:32 PM UTC+8, Axel Wagner wrote:
>
> Hi,
>
> I can not really reproduce your results. I rewrote your code to use the
> builtin benchm
On Thu, 2 Feb 2017, at 09:20 AM, T L wrote:
>
>
> On Thursday, February 2, 2017 at 4:58:32 PM UTC+8, Axel Wagner wrote:
>> Hi,
>>
>> I can not really reproduce your results. I rewrote your code to use
>> the builtin benchmarking: http://sprunge.us/IfQc
>> Giving, on my laptop:
>>
>> Be
On Thursday, February 2, 2017 at 5:20:01 PM UTC+8, T L wrote:
>
>
>
> On Thursday, February 2, 2017 at 4:58:32 PM UTC+8, Axel Wagner wrote:
>>
>> Hi,
>>
>> I can not really reproduce your results. I rewrote your code to use the
>> builtin benchmarking: http://sprunge.us/IfQc
>> Giving, on my lap
On Thursday, February 2, 2017 at 4:58:32 PM UTC+8, Axel Wagner wrote:
>
> Hi,
>
> I can not really reproduce your results. I rewrote your code to use the
> builtin benchmarking: http://sprunge.us/IfQc
> Giving, on my laptop:
>
> BenchmarkAssertion-4 10 2.89 ns/op
> BenchmarkA
Hi,
I can not really reproduce your results. I rewrote your code to use the
builtin benchmarking: http://sprunge.us/IfQc
Giving, on my laptop:
BenchmarkAssertion-4 10 2.89 ns/op
BenchmarkAssertionOK-4 5 2.66 ns/op
BenchmarkBare-4 10
Type assertion is even slower than reflect:
https://play.golang.org/p/zvUTEKDfiL
assert: count=33554432 time taken=499.061188ms
direct: count=33554432 time taken=14.981847ms
method: count=33554432 time taken=176.977503ms
reflect: count=33554432 time taken=383.905004ms
On Thursday, February 2, 20
On Thursday, February 2, 2017 at 4:25:05 PM UTC+8, T L wrote:
>
>
>
> On Thursday, February 2, 2017 at 2:04:23 PM UTC+8, ChrisLu wrote:
>>
>> Go's type assertion seems quite slow. The added cost is too much if it
>> has to be in a tight loop. Here are the time taken on my laptop for the
>> foll
On Thursday, February 2, 2017 at 2:04:23 PM UTC+8, ChrisLu wrote:
>
> Go's type assertion seems quite slow. The added cost is too much if it has
> to be in a tight loop. Here are the time taken on my laptop for the
> following code.
>
> https://play.golang.org/p/cA96miTkx_
>
>
> chris$ time ./p
On Thursday, February 2, 2017 at 2:04:23 PM UTC+8, ChrisLu wrote:
>
> Go's type assertion seems quite slow. The added cost is too much if it has
> to be in a tight loop. Here are the time taken on my laptop for the
> following code.
>
> https://play.golang.org/p/cA96miTkx_
>
>
> chris$ time ./p
66 matches
Mail list logo
