Re: 1.5.0svn slow view updates
Jean-Marc Lasgouttes wrote: "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes: Darren> I'm not asking for confirmation of the part I just introduced, Darren> I only just said it. Darren> But I know what I saw and I've since reproduced it again at my Darren> end. Whatever is causing the slowdown I'm talking about, it Darren> closes with LyX so it's either LyX or something spawned by and Darren> waiting on LyX. Yes. The problem is to know what. Is the CPU charge unusually high when LyX is slow? Note that the cpu usage don't have to be high. He may have an accelerated display - in that case the cpu will be idle waiting for the display hardware to do the job. Slow hardware, bad hardware driver or LyX/qt painting the same stuff over and over may then result in slow action and also a not so busy cpu. Helge Hafting
Re: 1.5.0svn slow view updates
Bug added, see http://bugzilla.lyx.org/show_bug.cgi?id=3700 Have fun, Darren
Re: 1.5.0svn slow view updates
On Tue, 2007-05-22 at 15:34 +0200, Jean-Marc Lasgouttes wrote: > > "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes: > > Darren> Please give me a little credit - there's been confirmations > Darren> already. > >> Confirmation of the complex behavior you describe? I did not see > >> that. Nobody disputes that there is a general slowness problem. > > Darren> I'm not asking for confirmation of the part I just introduced, > Darren> I only just said it. > > Darren> But I know what I saw and I've since reproduced it again at my > Darren> end. Whatever is causing the slowdown I'm talking about, it > Darren> closes with LyX so it's either LyX or something spawned by and > Darren> waiting on LyX. > > Yes. The problem is to know what. Is the CPU charge unusually high > when LyX is slow? 7.6% CPU according to top. A large number of mouse-wheel clicks in a row guaranteed that LyX was busy scrolling the whole time. Around 45% CPU when scrolling fast - i.e. bug not active. I presume it's really higher but I can't click the wheel fast enough. In two out of two cases tried, resizing the window clears the fault. Have fun, Darren
Re: 1.5.0svn slow view updates
On Tuesday 22 May 2007 4:08:22 pm Jean-Marc Lasgouttes wrote: > He is on Suse. Could it be a bad clipboard interaction? klipper has been working without problems for quite some time, but it can be a suggestion to disable it and to see if the problem remains... Using Fedora and kde I don't have these kind of problems for years, so I doubt this could be the culprit, but it does not hurt to try. :-) > JMarc -- José Abílio
Re: 1.5.0svn slow view updates
> "Dov" == Dov Feldstern <[EMAIL PROTECTED]> writes: >> That was something I tried early on - turning it off had no >> effect. Dov> Good. I mean, I'm glad that the bidi algorithm is not the Dov> culprit. ;) OTOH, at least we would have known where to search :) JMarc
Re: 1.5.0svn slow view updates
Darren Freeman wrote: Next time, I'll make "top" always on top :) You can also try xload, it's somewhat less intrusive.
Re: 1.5.0svn slow view updates
Okay I have more to add. In one instance I was able to get it to toggle from fast to slow by selecting Document->TOC. It didn't speed up again with the TOC closed. I checked the output of "top" and found my system to be 100.0% idle. (!) And then I got it to go from slow to fast by resizing the LyX window. Which was meant to see the output of top while scrolling :) I couldn't reproduce it the same way again!!! Next time, I'll make "top" always on top :) Have fun, Darren
Re: 1.5.0svn slow view updates
Darren Freeman wrote: On Tue, 2007-05-22 at 16:36 +0300, Dov Feldstern wrote: I myself do not see this slowness. However, I suggest that people who experience this try turning off the RTL option (Tools -> Preferences -> Language settings -> Language -> Right-to-left language support). I seem to remember a comment somewhere saying that 70% of the time is spent in the bidi code, which is quite complex... Please let us know either way if this makes any difference (or also if you're experiencing this slowness with the setting already off). That was something I tried early on - turning it off had no effect. Good. I mean, I'm glad that the bidi algorithm is not the culprit. ;) But I didn't realise that restarting would speed it up again and I didn't check if it prevents it from getting slower. I don't know how to reproduce it on demand, although I expect to see it again tomorrow when I start editing some more. I can try it with RTL off. Probably takes me an hour of editing to think about it being slow so that's enough to get a couple of different settings in. I didn't actually mean that --- I was just worried that RTL in-and-of-itself might immediately slow things down. I would be very surprised if bidi is causing the effect you're describing here. Still, I guess it wouldn't hurt to check... Would be easier though to get another person to agree that they see the same thing and try the opposite setting :) Or figure out what causes it. (to the other developers waiting on me to respond.. sorry but it's bedtime here and as I can't ignore this bug you'll get an answer when I'm back into it :) Have fun, Darren
Re: 1.5.0svn slow view updates
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Darren Freeman wrote: >> On Tue, 2007-05-22 at 15:23 +0200, Pavel Sanda wrote: But I know what I saw and I've since reproduced it again at my end. Whatever is causing the slowdown I'm talking about, it closes with LyX >>> is it possible to show the file you are talking about ? >> I don't really want to publish a partly done thesis but I don't >> think it has anything to do with the particular document. I think >> you just have to do a lot of (a particular kind of) editing. >> >> You could probably start editing the user guide at random and get >> it to slow down. Abdelrazak> I use 1.5.0svn everyday and I never got it to slow down on Abdelrazak> Windows. He is on Suse. Could it be a bad clipboard interaction? JMarc
Re: 1.5.0svn slow view updates
Darren Freeman wrote: On Tue, 2007-05-22 at 15:23 +0200, Pavel Sanda wrote: But I know what I saw and I've since reproduced it again at my end. Whatever is causing the slowdown I'm talking about, it closes with LyX is it possible to show the file you are talking about ? I don't really want to publish a partly done thesis but I don't think it has anything to do with the particular document. I think you just have to do a lot of (a particular kind of) editing. You could probably start editing the user guide at random and get it to slow down. I use 1.5.0svn everyday and I never got it to slow down on Windows. Abdel.
Re: 1.5.0svn slow view updates
> I don't really want to publish a partly done thesis but I don't think it > has anything to do with the particular document. I think you just have i'm working with ~80 pages doc for a few days on slower hardware than you indicated and havent observed anything like that. until there is some way how to reproduce this, it will be difficult to help you. pavel
Re: 1.5.0svn slow view updates
On Tue, 2007-05-22 at 16:36 +0300, Dov Feldstern wrote: > I myself do not see this slowness. However, I suggest that people who > experience this try turning off the RTL option (Tools -> Preferences -> > Language settings -> Language -> Right-to-left language support). I seem > to remember a comment somewhere saying that 70% of the time is spent in > the bidi code, which is quite complex... > > Please let us know either way if this makes any difference (or also if > you're experiencing this slowness with the setting already off). That was something I tried early on - turning it off had no effect. But I didn't realise that restarting would speed it up again and I didn't check if it prevents it from getting slower. I don't know how to reproduce it on demand, although I expect to see it again tomorrow when I start editing some more. I can try it with RTL off. Probably takes me an hour of editing to think about it being slow so that's enough to get a couple of different settings in. Would be easier though to get another person to agree that they see the same thing and try the opposite setting :) Or figure out what causes it. (to the other developers waiting on me to respond.. sorry but it's bedtime here and as I can't ignore this bug you'll get an answer when I'm back into it :) Have fun, Darren
Re: 1.5.0svn slow view updates
On Tue, 2007-05-22 at 15:23 +0200, Pavel Sanda wrote: > > But I know what I saw and I've since reproduced it again at my end. > > Whatever is causing the slowdown I'm talking about, it closes with LyX > > is it possible to show the file you are talking about ? I don't really want to publish a partly done thesis but I don't think it has anything to do with the particular document. I think you just have to do a lot of (a particular kind of) editing. You could probably start editing the user guide at random and get it to slow down. Have fun, Darren
Re: 1.5.0svn slow view updates
Hi! I myself do not see this slowness. However, I suggest that people who experience this try turning off the RTL option (Tools -> Preferences -> Language settings -> Language -> Right-to-left language support). I seem to remember a comment somewhere saying that 70% of the time is spent in the bidi code, which is quite complex... Please let us know either way if this makes any difference (or also if you're experiencing this slowness with the setting already off). Thanks! Dov
Re: 1.5.0svn slow view updates
> "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes: Darren> Please give me a little credit - there's been confirmations Darren> already. >> Confirmation of the complex behavior you describe? I did not see >> that. Nobody disputes that there is a general slowness problem. Darren> I'm not asking for confirmation of the part I just introduced, Darren> I only just said it. Darren> But I know what I saw and I've since reproduced it again at my Darren> end. Whatever is causing the slowdown I'm talking about, it Darren> closes with LyX so it's either LyX or something spawned by and Darren> waiting on LyX. Yes. The problem is to know what. Is the CPU charge unusually high when LyX is slow? JMarc
Re: 1.5.0svn slow view updates
Darren Freeman wrote: On Tue, 2007-05-22 at 14:24 +0200, Abdelrazak Younes wrote: Darren Freeman wrote: I restarted LyX and created a new document - problem is gone. Even after opening my thesis, problem isn't apparent. It looks like you may have to do actual editing of an actual thesis to reproduce this! (Hence I'm sure some of the developers are wondering what I'm on about.) Yep. I really don't understand what could be the cause of the problem you're describing. I'd say it's not LyX fault but perhaps some other program that is slowing down your computer. ROFL! Oh wait, you're serious. :( I used the conditional. Please give me a little credit Sure, I don't say that you're wrong, sorry. - there's been confirmations already. As JMarc said none that confirms what you describe. The biggest speed problem is on Mac not on X11 (except for the scroll lag problem reported by Helge but that is something else). If you can produce a profile we can investigate the issue. Abde.
Re: 1.5.0svn slow view updates
Stefan Schimanski wrote: Some profiling on Mac with Qt 4.2.x tells me: * 18% QPainter::drawTextItem * 18% QTextEngine::shape * 70% paintPar (includes the upper two) * 11% updateMetrics So 70% of the whole painting process goes into paintPar. Am I wrong that this part would go down more or less linearly in the number of paragraphs we draw? It should be possible to cache the Paragraph painting. That is, instead of the word level caching. The key would then be the paragraph id. Sounds promising... Only 36% seem to be spent in Qt though. I suspect there is more than that that does not immediately show in your profile. Those numbers come from sliding around the User Manual with the scrollbar. Probably all that needs a deeper analysis, e.g. maybe the numbers for other items go up without drawing (by caching effects...). Instead of doing partial redraw, I would use a QPixmapCache to cache word painting. The main problem in Mac is that Qt is damned slow at font metrics calculation. And Qt needs to recalculate the font metrics for each text painting. But caching small transparent pixmaps of painted words inside QLPainter we can speedup painting tremendously. I've played a bit with this approach some months ago and it is certainly doable. Interesting approach. One should implement a prototype and see what happens. I had a prototype once. It was quite easy to implement. Once I find some time I'll try to redo it again. Abdel.
Re: 1.5.0svn slow view updates
> But I know what I saw and I've since reproduced it again at my end. > Whatever is causing the slowdown I'm talking about, it closes with LyX is it possible to show the file you are talking about ? pavel
Re: 1.5.0svn slow view updates
On Tue, 2007-05-22 at 14:48 +0200, Jean-Marc Lasgouttes wrote: > > "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes: > > >> Yep. I really don't understand what could be the cause of the > >> problem you're describing. I'd say it's not LyX fault but perhaps > >> some other program that is slowing down your computer. > > Darren> ROFL! Oh wait, you're serious. :( > > Darren> Please give me a little credit - there's been confirmations > Darren> already. > > Confirmation of the complex behavior you describe? I did not see > that. Nobody disputes that there is a general slowness problem. I'm not asking for confirmation of the part I just introduced, I only just said it. But I know what I saw and I've since reproduced it again at my end. Whatever is causing the slowdown I'm talking about, it closes with LyX so it's either LyX or something spawned by and waiting on LyX. Have fun, Darren
Re: 1.5.0svn slow view updates
Some profiling on Mac with Qt 4.2.x tells me: * 18% QPainter::drawTextItem * 18% QTextEngine::shape * 70% paintPar (includes the upper two) * 11% updateMetrics So 70% of the whole painting process goes into paintPar. Am I wrong that this part would go down more or less linearly in the number of paragraphs we draw? Only 36% seem to be spent in Qt though. Those numbers come from sliding around the User Manual with the scrollbar. Probably all that needs a deeper analysis, e.g. maybe the numbers for other items go up without drawing (by caching effects...). Instead of doing partial redraw, I would use a QPixmapCache to cache word painting. The main problem in Mac is that Qt is damned slow at font metrics calculation. And Qt needs to recalculate the font metrics for each text painting. But caching small transparent pixmaps of painted words inside QLPainter we can speedup painting tremendously. I've played a bit with this approach some months ago and it is certainly doable. Interesting approach. One should implement a prototype and see what happens. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: 1.5.0svn slow view updates
> "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes: >> Yep. I really don't understand what could be the cause of the >> problem you're describing. I'd say it's not LyX fault but perhaps >> some other program that is slowing down your computer. Darren> ROFL! Oh wait, you're serious. :( Darren> Please give me a little credit - there's been confirmations Darren> already. Confirmation of the complex behavior you describe? I did not see that. Nobody disputes that there is a general slowness problem. JMarc
Re: 1.5.0svn slow view updates
On Tue, 2007-05-22 at 14:24 +0200, Abdelrazak Younes wrote: > Darren Freeman wrote: > > I restarted LyX and created a new document - problem is gone. Even after > > opening my thesis, problem isn't apparent. It looks like you may have to > > do actual editing of an actual thesis to reproduce this! (Hence I'm sure > > some of the developers are wondering what I'm on about.) > > Yep. I really don't understand what could be the cause of the problem > you're describing. I'd say it's not LyX fault but perhaps some other > program that is slowing down your computer. ROFL! Oh wait, you're serious. :( Please give me a little credit - there's been confirmations already. Have fun, Darren
Re: 1.5.0svn slow view updates
Stefan Schimanski wrote: Looking through the painting code... Is there a good reason that we don't do partial redraws while scrolling? Theoretically no. In practice, the way we do painting is inherited from the multi-frontend approach. There are certainly things that can be optimized. I mean a lot of the screen might be repaintable by just bitblt'ing the old image a bit upwards or downwards. For the usual cursor movement this is not that important because it is scrolled not so often (we might still get a speed up of two because it's scrolled halfpagewise). But scrolling by sliding the scrollbar or using the mouse wheel triggers many more redraw. Instead of doing partial redraw, I would use a QPixmapCache to cache word painting. The main problem in Mac is that Qt is damned slow at font metrics calculation. And Qt needs to recalculate the font metrics for each text painting. But caching small transparent pixmaps of painted words inside QLPainter we can speedup painting tremendously. I've played a bit with this approach some months ago and it is certainly doable. Abdel.
Re: 1.5.0svn slow view updates
Darren Freeman wrote: Further to my earlier email, I suspect that the slowness is due to gradually accumulating cruft in internal data structures. Maybe not a memory leak but conceptually similar, possibly fragmentation or lists that accumulate stale junk. I had my thesis open, and editing was so slw. I created a new document, and typing in this one I found out that editing was also just as slow. Hmmm, I thought, and closed my thesis. Again, editing the new document was painfully slow! I restarted LyX and created a new document - problem is gone. Even after opening my thesis, problem isn't apparent. It looks like you may have to do actual editing of an actual thesis to reproduce this! (Hence I'm sure some of the developers are wondering what I'm on about.) Yep. I really don't understand what could be the cause of the problem you're describing. I'd say it's not LyX fault but perhaps some other program that is slowing down your computer. Abdel.
Re: 1.5.0svn slow view updates
Stefan Schimanski wrote: Looking through the painting code... Is there a good reason that we don't do partial redraws while scrolling? I mean a lot of the screen might be repaintable by just bitblt'ing the old image a bit upwards or downwards. For the usual cursor movement this is not that important because it is scrolled not so often (we might still get a speed up of two because it's scrolled halfpagewise). But scrolling by sliding the scrollbar or using the mouse wheel triggers many more redraw. Good point, LyX 1.5 definitely needs some optimization. Are you capable of doing this, or could you at least write an entry about this in bugzilla.lyx.org? Helge Hafting
Re: 1.5.0svn slow view updates
> "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes: >> Did you compile with --disable-stdlib-debug? This is on for >> development versions and has a bit cost in performance. Darren> Doing that now, wasn't aware of it. Perhaps there should be Darren> something mentioned in INSTALL under svn checkouts. I presume Darren> this isn't enabled by default when building from a release... Darren> In fact is it really necessary for us plebs who don't generate Darren> stack traces but just want to test the svn on real work? Darren> Shouldn't that option be disabled by default? Developers can Darren> be trusted to enable it if needed. In beta releases and release candidates (and stable releases of course), this is turned off by default. In 1.5.0svn mode it is on. The option is very useful because it detects some bugs we would not see otherwise. JMarc
Re: 1.5.0svn slow view updates
Further to my earlier email, I suspect that the slowness is due to gradually accumulating cruft in internal data structures. Maybe not a memory leak but conceptually similar, possibly fragmentation or lists that accumulate stale junk. I had my thesis open, and editing was so slw. I created a new document, and typing in this one I found out that editing was also just as slow. Hmmm, I thought, and closed my thesis. Again, editing the new document was painfully slow! I restarted LyX and created a new document - problem is gone. Even after opening my thesis, problem isn't apparent. It looks like you may have to do actual editing of an actual thesis to reproduce this! (Hence I'm sure some of the developers are wondering what I'm on about.) Have fun, Darren
Re: 1.5.0svn slow view updates
On Tue, 2007-05-22 at 10:13 +0200, Jean-Marc Lasgouttes wrote: > > "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes: > > Darren> Hi all, I know this was/is_being discussed in some form or > Darren> another but I want to weigh in. > > Darren> On my system, AthlonXP3000+ w/ 1GB RAM, OpenSUSE 10.2, I find > Darren> the SVN to be rather slow. I've jumped from the 1.3/XForms > Darren> world into the 1.5/Qt4 and can hardly believe the change in > Darren> performance. > > Did you compile with --disable-stdlib-debug? This is on for > development versions and has a bit cost in performance. Doing that now, wasn't aware of it. Perhaps there should be something mentioned in INSTALL under svn checkouts. I presume this isn't enabled by default when building from a release... In fact is it really necessary for us plebs who don't generate stack traces but just want to test the svn on real work? Shouldn't that option be disabled by default? Developers can be trusted to enable it if needed. Have fun, Darren
Re: 1.5.0svn slow view updates
Looking through the painting code... Is there a good reason that we don't do partial redraws while scrolling? I mean a lot of the screen might be repaintable by just bitblt'ing the old image a bit upwards or downwards. For the usual cursor movement this is not that important because it is scrolled not so often (we might still get a speed up of two because it's scrolled halfpagewise). But scrolling by sliding the scrollbar or using the mouse wheel triggers many more redraw. Stefan Am 22.05.2007 um 10:13 schrieb Jean-Marc Lasgouttes: "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes: Darren> Hi all, I know this was/is_being discussed in some form or Darren> another but I want to weigh in. Darren> On my system, AthlonXP3000+ w/ 1GB RAM, OpenSUSE 10.2, I find Darren> the SVN to be rather slow. I've jumped from the 1.3/XForms Darren> world into the 1.5/Qt4 and can hardly believe the change in Darren> performance. Did you compile with --disable-stdlib-debug? This is on for development versions and has a bit cost in performance. JMarc JMarc PGP.sig Description: Signierter Teil der Nachricht
Re: 1.5.0svn slow view updates
> "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes: Darren> Hi all, I know this was/is_being discussed in some form or Darren> another but I want to weigh in. Darren> On my system, AthlonXP3000+ w/ 1GB RAM, OpenSUSE 10.2, I find Darren> the SVN to be rather slow. I've jumped from the 1.3/XForms Darren> world into the 1.5/Qt4 and can hardly believe the change in Darren> performance. Did you compile with --disable-stdlib-debug? This is on for development versions and has a bit cost in performance. JMarc JMarc
Re: 1.5.0svn slow view updates
On Tue, 2007-05-22 at 08:14 +0200, Anders Ekberg wrote: > > Darren Freeman > > A couple hundred milliseconds per mouse wheel scroll click isn't okay, > > dammit! > Did you try to compile with QT4.3 (pre-version)? > > At least on a Mac it improves things with about 30% (as compared to > 4.2.x). Typing in notes is still v e r y slow, though. 4.2.1 binaries which come with OpenSUSE 10.2 Still I find it hard to believe this is the problem. Surely not... Have fun, Darren
Re: 1.5.0svn slow view updates
Am 22.05.2007 um 08:14 schrieb Anders Ekberg: Darren Freeman Mon, 21 May 2007 20:05:26 -0700 Hi all, I know this was/is_being discussed in some form or another but I want to weigh in. On my system, AthlonXP3000+ w/ 1GB RAM, OpenSUSE 10.2, I find the SVN to be rather slow. I've jumped from the 1.3/XForms world into the 1.5/ Qt4 and can hardly believe the change in performance. A couple hundred milliseconds per mouse wheel scroll click isn't okay, dammit! ... Did you try to compile with QT4.3 (pre-version)? At least on a Mac it improves things with about 30% (as compared to 4.2.x). Typing in notes is still v e r y slow, though. I have to strongly agree with Darren here. I nearly stopped using the mouse wheel because it is so slow and therefore hard to control. In zero time I sometimes jump from the middle to the end of my thesis (no, not because it's so short :-) ). 30% are peanuts here. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: 1.5.0svn slow view updates
Darren Freeman Mon, 21 May 2007 20:05:26 -0700 Hi all, I know this was/is_being discussed in some form or another but I want to weigh in. On my system, AthlonXP3000+ w/ 1GB RAM, OpenSUSE 10.2, I find the SVN to be rather slow. I've jumped from the 1.3/XForms world into the 1.5/Qt4 and can hardly believe the change in performance. A couple hundred milliseconds per mouse wheel scroll click isn't okay, dammit! ... Did you try to compile with QT4.3 (pre-version)? At least on a Mac it improves things with about 30% (as compared to 4.2.x). Typing in notes is still v e r y slow, though. /Anders
1.5.0svn slow view updates
Hi all, I know this was/is_being discussed in some form or another but I want to weigh in. On my system, AthlonXP3000+ w/ 1GB RAM, OpenSUSE 10.2, I find the SVN to be rather slow. I've jumped from the 1.3/XForms world into the 1.5/Qt4 and can hardly believe the change in performance. A couple hundred milliseconds per mouse wheel scroll click isn't okay, dammit! My laptop is rendered incapable of editing my thesis because of this (933MHz/1GB, same OS). Yet there are no graphics visible within the window, just a bunch of regular text. I don't win anything when I close all insets so the existence of the graphics probably isn't it either. Also I often find myself typing a word (say into a fresh Note) and waiting a couple of seconds before the characters start appearing one at a time. Maybe I'm unlucky and an auto-save is happening etc. It's as though there is way too much re-calculating going on after every change. Or perhaps the size of my document is contributing more than it should, any operations like this ought to be O(1) or O(n^0.5), not O(n) or worse. Scrolling should be dead simple, and editing a paragraph usually doesn't affect the following paragraph positions. I think if 1.5.0 went out like this then a lot of people who didn't already love LyX would migrate to something else. Maybe it's just me. But my system config isn't all that uncommon and I doubt it is the distro. Have fun, Darren
