mint17.2，libre 4.3.6

有个很长的小说，300多万字，纯文字，odt，以前我用mint 17.1，4.2版本做好的。总是打不开，libre死机，cpu满载！别的小一点的文件没任何问题。好几天都在折腾这个事，今天有空，一定要搞个水落石出。在几天前，我就下了新版本，还是不行。重装旧版本，也是不行。我想，是不是我的设置问题，就删了所有设置，重新设置，不行。试着缺省设置，咦？可以了。慢慢的增加设置，偶然发现，当我把导航和样式工具栏停靠在侧边时，去打开文件就会死机。只有没有工具栏停靠在侧边时，就可以！工具栏浮动也可以，只要不停靠侧边，就行！

不知道为什么，说出来给大家一个参考。

可以尝试给他们反馈

到 工具 -》选项 -》内存， 把 “用于LibreOffice" 增加到100M，看是否可以解决问题。

如果可以的话，想办法把该odt文档传上来让我们试看看。

[/quote]

到 工具 -》选项 -》内存， 把 “用于LibreOffice" 增加到100M，看是否可以解决问题。

如果可以的话，想办法把该odt文档传上来让我们试看看。[/quote]


我都设置了256M也不行。

我也找了一个大文件试试，（word 2003 无图，仅文字的 doc 中文文档），247页，不包括空格25万字，包含空格27万字，文件大小 1.3M 。
配置CPU E3-1230 V2，四核八线程，内存4G，系统 UbuntuStudio 15.04 。
LibreOffice 5.0.1.2 没有修改内存设置，依然保持默认设置。

打开花费了4分钟又20秒，打开的过程注意看了一下资源占用情况，CPU八线程只有一个线程在使用，且占满100%，内存才用了一点点。
由于还有其它7个线程可用，所以打开过程中没有影响电脑其它软件的正常使用。
打开后，翻页时，又是只有一个线程在使用，且占满100%，如果是鼠标点击翻页、或者按PageDown还好，
如果是鼠标拖动滚动条翻页，这时会影响整个桌面，反应停滞（假死），等了很久翻页完成后，桌面才恢复正常。

然后另存为 odt 文件后，情况改善很多，鼠标拖动滚动条翻页尽管有点延迟，没有出现某个线程100%占用而假死的情况，不影响桌面其他软件。
此外，再次重新打开这个新保存的 odt 文件时（文件大小 350K），也是CPU八线程只有一个线程在使用，且占满100%，也要花费4分钟左右（稍少）。
与打开 doc 文件不同的是，文字可以在没打开全部文档时就提前显现，也可以提前翻页（尽管有延迟），打开 doc 文件则是窗口空白要等4分多钟以后才见字。

我也找了些小说来试一下，275万字。发现情况还是很乐观的。

1、如果是打开纯文字的txt格式文档，那么会卡几秒钟才能翻页或用滚动条。如果正处于LibreOffice对文件进行分页期间（大概要10秒），那么会冻结LO的窗口，但不影响其它程序的运行。

2、如果保存为ODT文件，并且应用了“格式和样式”后（我把所有文本的样式从“预格式化的文本”更改为“默认样式”，并给小说的章节加上标题样式）。则打开速度和拉动滚动条的速度基本不受影响。打开5秒内完成，打开进度条结束后，即可平滑流畅地拉动滚动条、翻页、导航等等。

系统：Xubuntu 15.04 AMD64，CPU i5集显，内存4G。
LibreOffice：5.0.2.2官方版本（内存调为256m）

测试文件，分卷压缩为3个：

LibreOffice 5.0.2.2 打开纯文字大文件的操作屏幕录像：
打开速度与操作的反响速度还是很乐观的。
设置格式与样式前，明显卡顿几秒，设置格式和样式，保存为ODT后，卡顿明显消除。

录像8M，分卷压缩为5个文件：

LibreOffice在读取及储存时只能用到一线程的CPU，这一点迟早会改善的。

附上一个测试的odt文档，虽然只有两千万个字，在LibreOffice (5.0.1.2)里操作起来相当困难，尤其是在储存时，整个电脑会被停滞好（最少）几秒钟（或十几秒钟）。

换成Apache OpenOffice (4.1.1)，储存时虽然有“一点点”慢，但一切似乎蛮正常的。

把LibreOffice更新到（5.0.2.2）以后，情况好了不少，不过好像还没有Apache OpenOffice稳。

Apache OpenOffice是为了这个测试才特别装的。因为LibreOffice更新的脚步很块，一般我们总以为OpenOffice已死了。经过这次经验以后，也许事情可能并不是那么简单。（不过很高兴有两个重量级的开放办公室套件在竞争。）

我们下载，cat，再解压缩以后，用 LibreOffice (5.0.1.2 及 5.0.2.2）读入及再储存，都没有问题，速度也很快。但请参阅上帖。

使用 LibreOffice 5.0.2.2打开你提供的测试文件，打开需20秒，修改后保存需70秒左右（CPU Intel Core2 T9600 @ 2.80GHz）。
除了打开与保存的时间显得长些外，其他基本操作还算正常。
考虑到两千万字，被分为一万五千多个页面，这样的卡顿也算可接受的范围内了。
（之前测试的是三百万字，操作还算流畅，这是两千万字，字数增长了近7倍了）

将你提供的两千万测试文字导入到MS Word 2007中试一下，也同样会卡在重新分页上。
毕竟都要渲染出WYSIWYG的页面效果，估计这是导致卡顿的主要原因。
但Word 2007在拉动滚动条时没有让页面跟随滚动，可能是以此避开不断渲染页面所带来的卡顿，但却无法快速浏览各页面效果。总之是各有利弊。

同样的odt文件，同样的libre版本及设置，在mint17.1上完全没有这个问题，很正常，mint 17.2就会卡了，很是莫名。

我们换了另一台机器做试验，大致结果如下：

LibreOffice 5.0.2.2: ~40秒
Apache OpenOffice 4.1.1: ~25秒

odt 文档大小： 576.4 kB
把该odt文档打开后重新储存为 txt， 文档大小膨胀了100倍（不是 100%），到 60.7MB！

读取该 .txt 文档（60.7MB）时，Apache OpenOffice 是瞬间的，LibreOffice 则要 5 ～ 10 秒。

我们也把该 .odt 文档 （576.4kB）解压缩，所得到的（解压缩过的）XML 档案有69.5MB。用Firefox读取，时间约 1.5 分钟。

从这个小实验看起来，关键的步骤是在XML parsing，LibreOffice 比Firefox要快很多，但Apache OpenOffice，最少在这一方面要比LibreOffice还要好。

很重要的一点被我忽略了；it turned out to be critically important!

原来的odt文档，乃是从网页copy + paste到LibreOffice里，再膨胀到两千万字，这可能是问题之所在。

我们把它转成 .txt档后，再储存为odt（见附件），读起来就完全正常了。这个新odt档案解压缩后，它的XML档案有63MB，因此前面所做的假设应该是不对的。

这几个测试文件下载后，找开很正常，没有卡的现象，翻页也不卡。
我是4G内存，LIBREOFFICE是最新版，内存设置改过:
用于Librefoffice 500M
每个对象的内存 10M
其它一切默认，字体安装了不少～