Re: [go-nuts] Performance issue with os.File.Write

As Jan said "apples and oranges", in this case comparing *os.Stdout with C File *stdout is not fair. The equivalent of *os.Stdout in C is the filedescriptor 1 (STDOUT macro), and the equivalent of *os.Stdout.Write is write(2) (the syscall), not fwrite or fputs. If you retry your microbenchmark

Re: [go-nuts] when do you use sync.Mutex instead of sync.RWMutex

thank you all for the great answers. now I know when I should use "RWMutex" instead of "Mutex". ;) 2020년 12월 21일 월요일 오전 1시 44분 1초 UTC+9에 mar...@gmail.com님이 작성: > Code using a simple sync.Mutex is also simpler, since you only have one > way to lock and unlock and you don't have to think about

Re: [go-nuts] Performance issue with os.File.Write

And os.Stdout (and friends) are all regular *os.File objects (which as Jan said, don't buffer). It was non-intuitive to me that stdout didn't buffer by default, because it's such a bad thing for efficiently writing lots of output, but I guess it makes sense when you want terminal output to

Re: [go-nuts] The GitHub Vet Project

On Sun, Dec 20, 2020 at 8:38 PM K. Alex Mills wrote: > During a Q session at this year's GopherCon, some members of the Go > language team indicated a willingness to modify the behavior of range loops > if we can be reasonably certain that the change will not cause incorrect > behavior in

[go-nuts] Generics, please go away!

I think people who want generics added to Go should go and program in Java or C++. Adding generics to Go will ruin the beautiful simplicity of the language and I haven't found a single example in which adding generics to Go pays off. Even with the examples of having two almost identical

[go-nuts] The GitHub Vet Project

Hello Gophers! During a Q session at this year's GopherCon, some members of the Go language team indicated a willingness to modify the behavior of range loops *if* we can be reasonably certain that the change will not cause incorrect behavior in current

Re: [go-nuts] What are debian:buster-slim advantages vs alpine ones?

Most of the issues presented here are only relevant for CGO and other programming languages, not Go. Also, could anyone share references about the security problems in Alpine? I may say Windows is more secure and faster than Linux (or the opposite), but without any evidence, it is just a

Re: [go-nuts] when do you use sync.Mutex instead of sync.RWMutex

Code using a simple sync.Mutex is also simpler, since you only have one way to lock and unlock and you don't have to think about lock type when writing code. In my opinion, use sync.Mutex, and if it proves to be inefficient, start investigating alternatives. In most cases, your simple code will

Re: [go-nuts] when do you use sync.Mutex instead of sync.RWMutex

A cache almost always uses a RW mutex or a lock free technique like copy on write/CAS to avoid contention. A simple mutex is fine for less performance critical code with guaranteed exclusive/sequential access needs. Many transaction modes are implemented with a simple lock/mutex. > On Dec

Re: [go-nuts] when do you use sync.Mutex instead of sync.RWMutex

Unless I specifically know that a variable will be written rarely and read often, I tend to use `Mutex`. I'm too worried that the preferential treatment of write-locks in an `RWMutex` leads to surprising contention-issues if there isn't an overwhelming relationship between their frequencies. I

Re: [go-nuts] How to set the "godebug" environment variable from the go file?

On Wed, 16 Dec 2020, 21:29 Ian Lance Taylor, wrote: > On Wed, Dec 16, 2020 at 8:49 AM Sean wrote: > > > > hi all, > > i have a project I have to work with CGo. I want to disable some > > controls as they are not good enough right now. > > It works when I write "set godebug=cgocheck=0" on

Re: [go-nuts] Performance issue with os.File.Write

Ah, that is it, thank you! On Sunday, 20 December 2020 at 11:06:05 UTC Jan Mercl wrote: > On Sun, Dec 20, 2020 at 11:53 AM Arnaud Delobelle > wrote: > > > TLDR; a simple test program appears to show that Go's (*os.File).Write > is 10x slower than C's fputs (on MacOS). > > Apples and oranges.

Re: [go-nuts] Performance issue with os.File.Write

On Sun, Dec 20, 2020 at 11:53 AM Arnaud Delobelle wrote: > TLDR; a simple test program appears to show that Go's (*os.File).Write is 10x > slower than C's fputs (on MacOS). Apples and oranges. fputs buffers, os.File does not. Rewrite the benchmark using bufio. -- You received this message

[go-nuts] Performance issue with os.File.Write

Hi there! TLDR; a simple test program appears to show that Go's (*os.File).Write is 10x slower than C's fputs (on MacOS). While doing some benchmarking for my lua implementation in Go [1], I found very big differences between C Lua and and golua for benchmarks that do a lot of output to

Re: [go-nuts] when do you use sync.Mutex instead of sync.RWMutex

An RWMutex will block all new readers if a writer is waiting to acquire the lock, and that writer will only acquire the lock once all current readers are gone. Depending on the semantics of your application and the frequency of writes, that might constrain the throughput through the section

[go-nuts] when do you use sync.Mutex instead of sync.RWMutex

we usually both read and write for a value. not only read, nor write. with that, I feel RWMutex is always right choice. when should I use Mutex instead of RWMutex? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group