【已解决】TMP的恢复已关闭标签页的列表有轻量级替代方案吗？

RT
因为我设置的可恢复标签页数量比较多，每次点开已关闭标签页列表就要卡一下，大概800ms的样子，很不爽
之前用TU就完全没有这个问题

请问有没有什么办法能禁用这个功能的？（虽然应该不会影响太多性能……

图片：2.png

为什么TMP的已关闭标签页列表打开会这么卡啊



****


忍不住就打开tmp搞了一下，发现果然加序号对性能影响不大；不知道如何对chrome进行profile，只能估计一下瓶颈
目前的方法是注释掉了其中整理标题的一段逻辑，因为这一段用到了makeURI，这玩意返回一个URI实例，要生成上百个对性能有一定影响；注释掉这一段以后，点按钮的卡顿时间就从800ms降到了200ms左右，基本上可以忍受了（但是那种拖泥带水的感觉仍然好不爽_(:3 」∠)_

剩下的200ms通过试错测试发现即使把循环内语句清空也没法减少，所以我琢磨着应该是tmp获取已关闭标签页的方法有问题，因为目测是通过JSON储存这些信息，然后点击按钮时进行了一次parse；但是原版好像也是用json，应该也不是这个的问题……



*****


再继续魔改之路发现，tmp这不是简单的“列表”，而是维护了一整套的绘画，准确描述应该是“已关闭标签页回收站”，打开“回收站”里的记录还会更新历史、删除“回收站”里的对应条目，代价就是打开的时候要卡半天，点击条目恢复的时候又要卡半天……
但是这么复杂的东西我用不到啊，我就想要TU那样的简单列表，相当于只是把原版的数量限制从10变成自定义，仅此而已，别无他求



******


事情的峰回路转总是让人措手不及……在绝望之余我关闭了tmp的整个恢复已关闭功能，希望用fx自带的；然后发现tmp是对原生该功能进行了破坏性改造（咳咳其实之前自己也说tmp是把标签相关功能整个重写了，关键时候就犯健忘），禁用了tmp的恢复，也就是禁用了自带的恢复。没办法只能再次打开，然后发现不卡了——惊喜之余，也担心只是清空记录后造成的幻觉，于是立马开上几百个url复杂的网页（感谢google提供又臭又长的url）把记录条目填满，然后再测试：确实不卡了！

虽然完全不明白为什么会这样，不过既然问题解决了就好，也许是tmp嫌弃tu遗留下来的记录？毕竟不是亲生的

把今天的2b经历贴在这里，希望能帮助到其他从tu转向tmp的朋友们



*********


后来发现另外的朋友好像有完全不卡的情况，仔细看了看原来是我历史记录太多了
一看about:config发现忘记设置哪个max_Pages，而且这玩意没有默认值，所以相当于“不清理”，现在约摸着有8万条了……

手工删除了一会发现非常痛苦，有库写入所以速度不敢恭维，同时选中多了还会假死，一次选4000，删除键按下后得哼哧哼哧跑好几分钟。这么删了2万条后歇了一会，看任务管理器发现firefox的I/O读取量已经达到了45G，甚至超过了清闲中的utorrent
于是转为去寻找能按时间删除的扩展；试了好几个没效果，琢磨着这些扩展应该都是根据以前的时间相关的config项工作的，现在没有了所以都失效了
看着剩下的好几万，于是把places复制出来放角落里供起来之后，果断删除了

再开fx，果然快了好多，但是地址栏变得蠢蠢的了，各种无法联想，这也是没有历史记录的弊端啊

我想应该有种屌爆的扩展，把超过xx天的访问数少于xx次的历史记录放到另外的sql里存档，根据某位湾湾的身体力行，表明这样至少能砍掉九成以上的条目（本来想给地址的但是已经删了找不到了 ），这样既能保证地址栏联想的能力又能大幅度降低性能的损失

然后一定需要进行全域深度搜索的时候，必须到历史管理界面才能搜索得完整的结果，这样又能保证数据的可到达性，充分发挥大历史记录的渊博性。毕竟联想和访问常见网站才应该是日常浏览的主题，翻阅历史应该是相对的小概率事件，为了小概率事件却要付出巨大的性能损失挺不划算的。如果像我设想的那样，完全可以常备历史库只留一两万，存档库要多大有多大，从2003年存到现在也未尝不可

不知道现在有没有这样的扩展呢

非常详细，多谢分享。我不用这些扩展的。