qweszxc：我没有保留任何这些报告，因为我上面认为和这个无关就没有报告了 。不管它了，是俺人品问题。回到原帖

总上传了吧？如果没有删除配置的话。。。

w153140：总上传了吧？如果没有删除配置的话。。。回到原帖

早就全部删除了。

qweszxc：早就全部删除了。回到原帖

好吧，希望你下次发生卡死后的时候最好发一下

不过3楼的建议依然不改变就是我还是那样建议。

qweszxc：不过3楼的建议依然不改变就是我还是那样建议。回到原帖

如果官方删除了还是卡死那你是不是还得扯其他功能？

w153140：如果官方删除了还是卡死那你是不是还得扯其他功能？回到原帖

“如果官方删除了还是卡死那你是不是还得扯其他功能？ ”  这个我是不会的，即便我现在很正常也不会卡死我还是坚持3楼的建议和1楼上面的第二个红色字体的建议。（1楼上面的第二个红色字体的建议这个和大数量书签使用密切相关有关的，基本上1千5百多个数量的火狐书签就已经急切迫切需要打开关闭再打开左侧栏书签侧栏后，一定务必就要能够有左侧栏书签侧栏的滚动条能够有记忆的功能了，何况很多人都有上万以上数量的火狐书签了，因此Mozilla官方在这个功能上不可等闲视之呀，因此这就是我为什么前面说是上上策）。

qweszxc：这个崩溃报告是没什么用的，因为这是火狐先卡死后被我用强制结束火狐进程关闭后的崩溃报告，而主要是火狐卡死后的这个报告没有的是无法反应出来的，火狐这时并不崩溃只是卡死，就是火狐崩溃并不是自动产生的崩溃，当然我如果乃着性子等上一段时间的话，火狐卡...回到原帖

所以你说的卡死，不是真的卡死，只是非常缓慢吧。
导入你的书签到一个新配置，如果能重现，就是你的书签太多，Firefox的侧栏处理能力（算法性能）跟不上。作为临时解决方案，你可以将书签备份（json）留好，删掉一些用不上的书签。
性能方面的问题，Firefox仍有不少，比如https://bugzilla.mozilla.org/show_bug.cgi?id=734643，官方没什么人手和兴趣修复。自然，更没兴趣移除一个还能用的功能。
如果能确定重现条件（哪怕是数万书签，用json做出来并不困难）和问题原因，没准会有人修正（至少是报告）。比如说，数万书签的层级结构、内容长度等是否重要，或者只是数量。

qweszxc：你好，我的火狐和配置都很正常的。我是经常开关书签侧边栏后首先会经常不时出现卡死火狐（CPU就突飙到70%以上），就是火狐被卡死了后再强制关闭火狐进程后火狐崩溃了。而你们不能重现的情况貌似是很正常的，因为这需要有上万以上（至少3万以上）数量的...回到原帖

一个经过压缩的配置文件5.8MB保存5万多项有啥好吹的？我还是那句话：你就是想得太多学得太少。了解数据压缩原理的人都不该觉得有什么特别的地方。
你这个卡一阵子又自己恢复的情况，你可以通过windows自带的资源监视器看看发生时的内存与磁盘使用状态，看看当时具体卡在什么上了

taoww：一个经过压缩的配置文件5.8MB保存5万多项有啥好吹的？我还是那句话：你就是想得太多学得太少。了解数据压缩原理的人都不该觉得有什么特别的地方。
你这个卡一阵子又自己恢复的情况，你可以通过windows自带的资源监视器看看发生时的内存与磁盘使...回到原帖

“一个经过压缩的配置文件5.8MB保存5万多项有啥好吹的？”  很好，这个我并没有主动再次去人为去压缩它，这个是火狐的bookmarkbackups文件夹里面书签本来就有的自然产生的容量。所以我为什么喊大家举手了看看如何了？当然这个大家一定要举手看看回答后才知道如何了，光靠吹是不知道的。请问你的容量是多少？如果你觉得不会侵犯你个人隐私的话可以回答最好有图，当然这个你这里请随意也可以不回答不回复。我的如下：

图片：ff3.jpg

qweszxc：你好，我的火狐和配置都很正常的。我是经常开关书签侧边栏后首先会经常不时出现卡死火狐（CPU就突飙到70%以上），就是火狐被卡死了后再强制关闭火狐进程后火狐崩溃了。而你们不能重现的情况貌似是很正常的，因为这需要有上万以上（至少3万以上）数量的...回到原帖

5万书签，我这里确实没办法重现这么大数量级书签的实验。不过我个人认为的确有可能是因为这个新增加的移动到右侧代码不完善（未考虑道这么多书签的情况）导致的卡顿。

不说几万个书签，尝试在Firefox 60 ESR的“我的足迹-未分类书签”中复制粘贴若干次弄出上百个书签，书签窗口都卡的要死（10+秒）。
持续Ctrl+B，确实看到有闪现在右侧，可能对性能有轻微影响。

Firefox 53~60“修复”的书签系统问题。

Firefox 58将原来的很多“同步”处理代码改成了异步。Bug 979280 - [meta]Replace the synchronous transaction manager in places with an asynchronous one
楼主你可以试一下Firefox 57，看是否有卡死问题。

qweszxc：“一个经过压缩的配置文件5.8MB保存5万多项有啥好吹的？”  很好，这个我并没有主动再次去人为去压缩它，这个是火狐的bookmarkbackups文件夹里面书签本来就有的自然产生的容量。所以我为什么喊大家举手了看看如何了？当然这个大家一定...回到原帖

呵呵，你再一次暴露出没什么知识又爱乱想的毛病。我哪里说是要你自己去动手压缩了，一看那个扩展名jsonlz4，就能想到是json格式的原始文件经过lz4压缩算法压缩后的。
就算你不知道json和lz4是什么，找个搜索引擎直接搜索一下jsonlz4也能很快明白。
这里有个解压缩jsonlz4格式的工具，你把它解压出来看看原始文件大小再来惊叹也不迟。https://github.com/avih/dejsonlz4

xxp2277：5万书签，我这里确实没办法重现这么大数量级书签的实验。不过我个人认为的确有可能是因为这个新增加的移动到右侧代码不完善（未考虑道这么多书签的情况）导致的卡顿。回到原帖

那个功能本质上就是交换个ordinal属性，影响一下界面布局顺序，如果这也能对性能有大影响，那firefox在日常网页浏览时早就卡成渣了。更何况楼主根本就没有启用这个功能

xxp2277：5万书签，我这里确实没办法重现这么大数量级书签的实验。不过我个人认为的确有可能是因为这个新增加的移动到右侧代码不完善（未考虑道这么多书签的情况）导致的卡顿。回到原帖

你说的很对而且很有这种可能虽然并不是所有人都这样（上面10楼w153140的火狐就很正常使用没问题），另外也很可能是楼主人品出问题。

taoww：呵呵，你再一次暴露出没什么知识又爱乱想的毛病。我哪里说是要你自己去动手压缩了，一看那个扩展名jsonlz4，就能想到是json格式的原始文件经过lz4压缩算法压缩后的。
就算你不知道json和lz4是什么，找个搜索引擎直接搜索一下json...回到原帖

显然上面这并不是我要说的意思，你理解错了别人的意思，说了其他的并不是我这里想要表达的东西。