21–30 of 131 posts
Nice can't wait to run some of our benchmarks against this. Go has the awesome property of always becoming a little bit faster every release. It's like your code becomes better without doing anything. Love it :)
Build time with 1.8.3:
real 0m7.533s
user 0m36.913s
sys 0m2.856s
real 0m6.830s
user 0m35.082s
sys 0m2.384s
1.8.3 : 19929736 bytes
1.9 : 20004424 bytes
[1] You can git-clone and try yourself: https://github.com/gravitational/teleport
I was looking forward to the fix for the dreaded Linux namespace handling problem: https://www.weave.works/blog/linux-namespaces-and-go-don-t-m... which kind of makes Go suck for many important container-related tasks. But apparently the effort has stalled... https://go-review.googlesource.com/c/go/+/46033
I am looking forward to 1. runtime/pprof package now include symbol information 2. Concurrent Map 3. Profiler Labels 4. database/sql reuse of cached statements 5. The os package now uses the internal runtime poller for file I/O.
> 4. database/sql reuse of cached statements !! that wasn't a thing until now?
Does anyone know of compile-time benchmarks spanning 1.4 through 1.9, along the lines of [1]? I see there's (more) parallel compilation in 1.9 - so that should improve elapsed time (but not reduce cpu time) of compilation. Would be nice to know if 1.9 is (still) on track catch up to/pass 1.4. [1] https://dave.cheney.net/2016/11/19/go-1-8-toolchain-improvem...
Go 1.4: Around 2.1s Go 1.9: Around 2.5s
So within 20% of 1.4, not bad. That's on an old MacBook Air, dual core 1.7 GHz i7, 8GB ram.
And of course the binary performance and GC pause times w/ 1.9 will be much better.
Here's the raw times: https://pastebin.com/ULDHPmVu
Two awesome things:
It was super-easy and fast to download and compile Go 1.4
It was completely painless to compile my old code with Go 1.9
I fucking love how nice it is to work with the Go ecosystem. <3
So this new concurrent map? Am I right in understanding it's designed for cases where you have a map shared between goroutines but where each goroutine essentially owns some subset of the keys in the map? So basically it's designed for cases like 'I have N goroutines and each one owns 1/N keys'?
It could just be one map shared by many goroutines, which normally causes a panic: fatal error: concurrent map writes
Please remember that sync.Map isn't type safe and is more optimised for reads.
https://en.wikipedia.org/wiki/Type_safety
> Type enforcement can be static, catching potential errors at compile time, or dynamic, associating type information with values at run-time and consulting them as needed to detect imminent errors, or a combination of both.
interface{} is type-checked at runtime. It's type-safe because because you can't e.g. fish out an integer out of interface{} value that represents a string. Runtime won't allow it.
You can either extract a string or the runtime will crash if you insist on extracting anything else. Unless you use unsafe package, in which case you explicitly want to skip type-safety.
In case someone cares about these things, I compared the build times and the binary sizes for 1.9 vs 1.8.3 using the open source project we maintain [1]. This is on a 6-core i7-5280K: Build time with 1.8.3: real 0m7.533s user 0m36.913s sys 0m2.856s Build time with 1.9: real 0m6.830s user 0m35.082s sys 0m2.384s Binary size: 1.8.3 : 19929736 bytes 1.9 : 20004424 bytes So... looks like the multi-threaded compilation ind…
Furthermore, when I see a second run that's faster than the first one, I immediately wonder if it's the cache being cold for the first run and warm for the second.
While I have your attention, https://zedshaw.com/archive/programmers-need-to-learn-statis... is worth reading.
Please add enum class