Open Miigon opened 2 years ago
这玩意儿是手动管理内存吧,忘了释放就泄露了,如果是这样为啥不用 c++
XMM主要场景是想要自主管理内存的场景,在Go中想要自主管理内存不经过GC是没办法的~ 只能字节流等等比较粗糙的方式,针对这种场景所以才开发了XMM。 XMM主要就是应对哪些从C++转到Go的想要自主管理内存,还有用Go无法管理内存想转到Rust的这些用户; 目前版本就是手动Free内存,不是不加上GC功能,是加了GC,就是跟go内置GC一样了,绕了一圈又回去了,所以才选择这种方式; 但是看未来发展方向,也可能会增加自动GC功能,大概率也是引用计数或三色标记这些算法;
感谢支持~
另外,本质来说,XMM是为了解决那些想自己管理内存,提升程序性能,并不被GC影响性能的开发者和应用场景;如果一个CURD场景的,完全没必要使用XMM,内置的map/slice等基本就够用了。 XMM就是为了底层解决高性能以及自主内存可控制不会被GC影响等场景的问题存在的,就是为了弥补Go内置没有能够自己管理内存操作存在的。Go gc是一个大黑盒,几乎不暴露任何接口,对很多追求极致性能或者是想内存可控的程序员来说是非常痛苦的,只有自己遇到才会懂,所以才开发了XMM。
感谢支持~
所以可以理解为这是一个内存池,然后tradeoff还是交换开发时间(手工跟踪管理对象生命周期)来换执行效率。大概清楚了,感谢。
@Miigon 这场景分析就很pragmatic,突然让我想到《程序员修炼之道》里的哲学
@Razorro 这本书中的方法和思想,在工程实践和技术批判思考上确实很有实效。这么一提突然感觉这本书确实值得推荐给身边的朋友读一读。感觉自己的很多实践上受这本书潜移默化的影响有很多,这回这么一说才意识到源头是它。
项目看起来很酷,但是在阅读完README之后并没有看到关于「取舍」、「适用场景」及 「不适用场景」 的描述。
一些比较好奇的点:
总结起来是:单从性能的角度,忽略额外的编码复杂度来讲:何时使用XMM而不使用go自带内存管理?更重要的是,何时使用go自带的内存管理而不使用XMM?