条件断点

背景 查看到delve这条issues，对于条件断点会导致程序变慢很多 package main import ( "fmt" "time" ) func main() { sum := int64(0) start := time.Now() for value := int64(0); value < 10000; value++ { sum += value »

godbg 介绍

Start a new project, the debugger on linux platform for go. This project is inspired by dlv github地址 背景 没想到这个项目最终还是沦为为一个玩具。初次有这个想法是因为发现 gdb调试golang代码是可以进入runtime的指令，而dlv却不可以。例如像map这种的初始化 s := make( »

nsq 支持分布式事务（四）

也许我就是个跑偏的人，这个系列越写越偏 基准测试 本来是跟原版里面./bench.sh做一些基准测试，在我这台垃圾电脑上面 写性能 最后发现如果没有SyncTimout（就是超时落盘）这个，dtnsq写竟然40w/s，而nsq才18w/s~20w/s 没办法加上了默认了SyncTimout(2s)，但是dtnsq也是30w/s 大家在落盘之前都是内存操作，如果有性能差异，我猜测是 channel导致的 读性能 »

go源码阅读 slice

slice 对于slice来说，其实源码部分并不多，主要看一下make slice、growslice、slicecopy和copy 编译阶段 make slice语句跟map一样，在compile的typecheck阶段，将MAKE节点偷偷换成OMAKESLICE节点 关于oppend的代码实在/usr/local/go/src/cmd/compile/internal/gc/ssa.go的func (s *state) append( »

go源码阅读 defer

defer 这个话题有点大，只是翻阅了关键代码，细节太多了 主要defer要弄明白两个函数，函数目录在/usr/local/go/src/runtime/panic.go中的deferproc和deferreturn deferproc //主要这里面都不能使用栈分裂，不能进行逃逸分析，因为defer是希望利用栈内存处理 //go:nosplit func deferproc(siz int32, fn *funcval) { ... d »

go NaN

NaN 之前阅读源码，发现golang的可比性和map里面都有NaN的特判 以前写js可知，NaN与任何浮点型比较都是false，包括它自己 // main.go package main import ( "fmt" "math" ) type TestFloat struct { Float64 float64 `json:"float64"` } func main() { mp := make(map[float64] »

go源码阅读 map

序 关于map的实现，我按照我的思路来看源码，中间尝试了挺多的case，最终选了一些来作为实例 可能跟网上其他人不太一样　 准备工作 首先做一些准备工作，跳过一下与编译无关的过程，例如搜索依赖关系　　　 样例代码 新建临时目录test_map，在该目录下写入样例代码 // main.go package main import ( "fmt" ) func test_map() { s := make(map[ »