What's the tradeoff?
Miigon opened this issue · comments
项目看起来很酷，但是在阅读完README之后并没有看到关于「取舍」、「适用场景」及 「不适用场景」 的描述。
一些比较好奇的点：
- 请问有不同情景下（对象大小、堆使用量etc）的benchmark吗？
- XMM的GC性能与go自带GC的比较？GC的频率以及单次GC耗时？
- “在面对成千上万的小对象场景中，不会因为 Go 本身 GC 机制带来任何的抖动” -- XMM的GC带来的抖动呢？如果是手工free的话，手工free部分的开销是多少？
- “不会内存泄露，并且内存管理不是粗糙的，而颗粒度细致的，完全尽量可媲美行业主流的内存管理分配器。” -- 有数据支撑吗？
- 大对象/小对象/大小混合对象下的内存占用overhead是多少？对比go？
总结起来是：单从性能的角度，忽略额外的编码复杂度来讲：何时使用XMM而不使用go自带内存管理？更重要的是，何时使用go自带的内存管理而不使用XMM？
这玩意儿是手动管理内存吧，忘了释放就泄露了，如果是这样为啥不用 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还是交换开发时间（手工跟踪管理对象生命周期）来换执行效率。大概清楚了，感谢。
