CC11001100

@Oliveria 是这个项目老哥： https://github.com/JSREI/ast-hook-for-js-RE ，有兴趣可以一起维护哈 😀

@unregister #44 啊老哥如果是内部框架的话谨慎着点，对于内部框架的快速上手可以多问问周围的同事领导，模仿着他们的方式去使用比较稳，而且这种内部自研框架一般坑会非常多，这种内部框架一般都是 fork 开源的框架进行二次开发甚至就是完全模仿，底层是照抄的，上层的 API 啥的改一改就变成自研的了，你花费在内部框架上面的时间学到的技能很可能不具有通用性，可以把精力着重放在学习内部框架的底层原理上，或者更多的是结合内部框架来理解它模仿的那个框架（比如某些公司基于 gprc 封装自己的 rpc 框架搞出来一堆上层的规范和协议啥的，这个时候就可以下钻把精力更多的放到更底层的 gprc 上而不是纠结于最上层的 API 啥的怎么调，底层原理这个技能是通用的，你离开了这家公司也有用，并且对你以后发展也有用），总结下来就是尽量去卷能够在你整个职业生涯中都能发挥作用的技能，加油祝好！ 😋

@somebody1 心理活动估计跟 #10 楼所说差不多，或者更严重一点的：

- 心里已经觉得你技术不太行或者出活不太行（大概率是出活，毕竟这个会影响到他 KPI ，如果只是技术不太行不影响到他利益的话他可能不会多嘴），但是又还没差到要干掉你的程度或者他因为个人情感啥的不太想干掉你（毕竟没有谁心理变态整天要开人，人都是有感情的，马仔能凑活着用就凑活着用），但是他能看到事情已经是在向很不好的那个方向发展了

- 考虑到你的自尊心他不能说得太直白，就随便聊聊估计

- 如果持续一段时间他觉得还没啥改善，估计就会着手开始换人了。。。

op 可以主动找 Leader 聊一聊，看看有没有更具体的建议啥的，如果只是某项技能上的缺失（比如某个技术框架、或者某些软素质的方法论啥的），你卷一卷学会了受益最大的是你自己，但是如果是要靠延长工作时间才能改善的，就只能六字真言，要么忍要么滚。。。 😂

七年过去了，op 怎么样了，得到当初想要的东西了吗

@nuk 是的老哥，所以压缩分为了两部分：

1. 一部分是栈内部的压缩，这一步相当于是所有的栈共享了一个全局字典来压缩自己内部的重复部分

2. 一部分是栈之间的压缩，完全相同的栈就直接引用同一个 id ，有点类似于 jvm 里的 fast throw 机制，完全相同的栈从第二次开始就是引用的之前的 id 而不重复存储，相当于把整个栈压缩为一个整数

对了怪我的背景故事介绍不完整，他那个工具调用栈不只是异常抛出，他那个工具是通过 java agent 技术给代码添加 hook 点来检出漏洞（原理跟 arthas 类似），每个 hook 点都会有对应的调用栈，hook 点是用户可配置的不可控，甚至可能会出现用户把每行代码都 hook 的情况。。。

@1423 #6 哈哈哈我有点慌呗，我在压缩这块还没太多经验属于刚入门还在各种探索寻找案例练手，我怕自己有想不到的点导致后面全都是错的心态就真崩了那，发到论坛里让大家喷一喷聊一聊能更完善一些有问题我也能及时调整，我之前出现过埋头造轮子造完才发现因为最开始一个很基础的东西没想对到后面全都是错的整个都白费劲哈哈哈。。。😂

@1423 预训练字典的方式也跟那个工具的作者讨论过他否定了，他的业务场景不太满足，数据拿不到那是个类似私有部署的 CLI 工具，要训练只能在用户自己的电脑上训练。。。🤣

@1423 通用的压缩算法大部分都是基于字典和偏移尽量消除重复数据，比较依赖的是压缩的时候的字典窗口大小和一次性被压缩的数据量的大小，调用栈是热数据需要能够随时查询不适合批量压缩，如果 gzip 只能针对单条调用栈进行压缩，那个工具的开发者现在已经是在这么做了，消耗的资源（ gzip 的内存、CPU 消耗等）与效果做性价比的话不是很理想（但也能凑活用。。。），所以才想着看看探索更极致的优化，当然这也只是一次尝试，也很可能还不如通用的压缩算法也说不好 😅

@kneo 代码在写了老哥，方案设计写了大概一个小时，只是感觉算法应该还有挺大优化空间，论坛里牛逼大佬比较多先发出来让大家喷一下，这样我在写的时候也能及时调整，代码估计要写个两三天国庆后应该能发出来具体效果 https://github.com/stack-database 😀