update: using branches does not help. Moving around in a large doc (example: userGuide) is sluggy too. Weird. This must be something in my config... I tried 1.6.4 (ubuntu) 1.6.6 (sabayon) and 2alpha 3 (ubuntu). Same problem. The problem is that moving the cursor (not even typing, as usersGuide is read-only) takes a long time, maybe .5 sec per character. Doesn't feel speedy... compared with a small doc, where it flies. Best, -Jose
Jose Quesada, PhD. Max Planck Institute, Center for Adaptive Behavior and Cognition, Berlin http://www.josequesada.name/ http://twitter.com/Quesada On Sat, Jun 12, 2010 at 9:56 PM, Jose Quesada <ques...@gmail.com> wrote: > ok, attached is an example. > At 40 headins it is kind of too slow for actuall work. > > Turning autocompletion off doesn't help. Neither does turning off inline > spelling. > htop shows lyx using little memory and cpu. Performance degrades lineally > with number of headings. > > If you could reproduce this on other systems, then I think we have a bug. > > Best, > -Jose > > Jose Quesada, PhD. > Max Planck Institute, > Center for Adaptive Behavior and Cognition, > Berlin > http://www.josequesada.name/ > http://twitter.com/Quesada > > > On Sat, Jun 12, 2010 at 9:48 PM, Jose Quesada <ques...@gmail.com> wrote: > >> @Steve,16 Gb of ram, cpu iddle... I don't think it's a matter of >> resources. >> @Julien, you narrowed down the problem! when I close the outline pane, >> everything is fast. Unfortunately, for my use case I need it open... >> >> I wonder if Rob Oakes, who has been working on the outliner code, could >> improve performance. >> Maybe there's an inconsistency on the headings on this particular file >> that make it slow... >> >> I'm going to generate a file with only say 100 headings, but only two >> levels, and then increase the complexity until I hit the slow down... >> Will report back. >> >> Best, >> -Jose >> >> Jose Quesada, PhD. >> Max Planck Institute, >> Center for Adaptive Behavior and Cognition, >> Berlin >> http://www.josequesada.name/ >> http://twitter.com/Quesada >> >> >> On Sat, Jun 12, 2010 at 8:16 PM, Steve Litt <sl...@troubleshooters.com>wrote: >> >>> On Saturday 12 June 2010 11:55:20 Jose Quesada wrote: >>> > Hi, >>> > >>> > I'm not sure if this is only on my particular doc, but it seems to me >>> > that lyx chokes on documents with many subsections? >>> > It's a notes doc. It may have close to a hundred headinds (section, >>> > subsection etc). >>> > Typing becomes slow. Even moving around with the arrow keys shows a >>> > noticeable delay. >>> > >>> > Since LyX is praised for working really well on longer documents, such >>> as >>> > books, I'm surprised. >>> > I tried 1.6.4 (ubuntu) 1.6.6 (sabayon) and 2alpha 3 (ubuntu). Same >>> problem. >>> > >>> > In this use case, there's almost as much 'section' content as there's >>> > 'default' paragraph content. Maybe this is abusing the design of >>> LyX...? >>> > >>> > Best, >>> > -Jose >>> >>> A long, long time ago, back in the Xforms days (yeah, let's not get >>> started on >>> that), a LyX version had a bug where a moderately long doc would allow >>> the >>> typist to outrun LyX. It was some problem with a specific algorithm >>> (maybe >>> shifting X characters by shifting 1 character X times, or something like >>> that). But since then, I haven't seen a Lyx version that let me (45 to 50 >>> wpm) >>> get ahead of LyX, even though I've written some fairly big books with >>> lots of >>> headings. My "Thriving in Tough Times" book has 112 Subsection headers: >>> >>> ===================== >>> sl...@mydesk:/d/at/books/mental$ cat thrive.lyx | grep "begin_layout >>> Subsection" | wc -lsl...@mydesk:/d/at/books/mental$ >>> 112 >>> sl...@mydesk:/d/at/books/mental$ >>> ===================== >>> >>> I'm using LyX 1.6.4 on Ubuntu 9.10 32bit with 3.4 GB of recognizeable >>> RAM. >>> >>> ===================== >>> sl...@mydesk:/d/at/books/mental$ lyx -version >>> LyX 1.6.4 (2009-08-22) >>> Built on Sep 22 2009, 23:23:06 >>> Configuration >>> Host type: i486-pc-linux-gnu >>> Special build flags: aiksaurus warnings use-aspell use-ispell >>> C Compiler: gcc >>> C Compiler LyX flags: >>> C Compiler flags: -g -O2 >>> C++ Compiler: g++ (4.4.1) >>> C++ Compiler LyX flags: >>> C++ Compiler flags: -g -O2 >>> Linker flags: >>> Linker user flags: -Wl,-Bsymbolic-functions -Wl,-z,defs >>> -Wl,--as- >>> ne eded -Wl,-z,defs -Wl,--as- >>> needed >>> Qt 4 Frontend: >>> Qt 4 version: 4.5.2 >>> Packaging: posix >>> LyX binary dir: /usr/bin >>> LyX files dir: /usr/share/lyx >>> >>> sl...@mydesk:/d/at/books/mental$ uname -a >>> Linux mydesk 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 05:23:09 UTC >>> 2010 >>> i686 GNU/Linux >>> sl...@mydesk:/d/at/books/mental$ head -n1 /proc/meminfo >>> MemTotal: 3346096 kB >>> sl...@mydesk:/d/at/books/mental$ >>> ===================== >>> >>> Always assuming you're not using a 2004 version that has this known bug, >>> I'd >>> suspect you might be running short on RAM, or you're using a VERY >>> underpowered >>> CPU, or something like that. >>> >>> If I were going to troubleshoot this, I'd reboot the machine and try >>> LyXing >>> the doc again. Either it's slow or it's not. If it's not, start looking >>> at >>> other software running concurrently with LyX. If it is, cut a copy of the >>> doc >>> in half and see whether it's just as slow, half as slow, or not slow at >>> all. >>> Continue doing this half splitting until you discover the factors >>> corresponding to slow behavior. >>> >>> StevET >>> >>> >>> Steve Litt >>> Recession Relief Package >>> http://www.recession-relief.US >>> Twitter: http://www.twitter.com/stevelitt >>> >>> >> >
