Re: [Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Andre Poenitz]

On Sat, Sep 24, 2005 at 09:11:19AM +0300, Martin Vermeer wrote:
> I propose to put the attached summarizing patch in, and test and
> profile again.

At least the update parts could be committed immediately as far as I am
coconcerned. They fix regressions.

Andre'

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Jean-Marc Lasgouttes]

> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:

Bennett> OK ... I've tried this, and it looks like
Bennett> --disable-assertions creates problems requiring that

Bennett> #include 

Bennett> be added to each of the following:

Bennett> src/factory.C src/messages.C src/text.C src/text2.C

I did that.

JMarc

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Jean-Marc Lasgouttes]

> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

Lars> Or almost... leave assertions in f.ex.

Jean-Marc> So, would the following patch be OK?

Applied.

JMarc

Re: [Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Martin Vermeer]

On Sat, 24 Sep 2005 10:34:25 +0100 Angus Leeming <[EMAIL PROTECTED]> wrote:

> Martin Vermeer wrote:
> > I propose to put the attached summarizing patch in, and test and
> profile
> > again.
> 
> My comments are those of someone who is entirely ignorant of this part
> of
> the code, so please take them with a pinch of salt. Well meaning
> interference :)
> 
> Angus
 
Taken in that spirit ;-)

 
> Why the two if statements rather than && ?
> Index: BufferView_pimpl.C
> -   if ((flags & Update::FitCursor) && fitCursor()) {
> -   forceupdate = true;
> -   vi = metrics(flags & Update::SinglePar);
> +   if (flags & Update::FitCursor) {
> +   if (fitCursor()) {
> +   forceupdate = true;
> +   vi = metrics();
> +   }

No reason. Result of experimentation that led nowhere.
 

> I think you should comment the code more so that your learning curve
> doesn't have to be repeated. How about:

Yes... right. More people should do that ;-)

...
 
> Why does this need to be inside the loop? Looks to me like "y1" and
> "y2"
> are overwritten on each iteration of the loop and that "y" and "pit"
> are
> available immediately afterwards.
> @@ -1379,13 +1377,27 @@ ViewMetricsInfo BufferView::Pimpl::metri
> for (lyx::pit_type pit = pit1; pit <= pit2; ++pit) {
> y += text->getPar(pit).ascent();
> theCoords.parPos()[text][pit] = Point(0, y);
> +   if (singlepar && pit == cursor_[0].pit()) {
> +   // collect cursor paragraph y's
> +   y1 = y - text->getPar(pit).ascent();
> +   y2 = y + text->getPar(pit).descent();
> +   }
> y += text->getPar(pit).descent();
> }
> I *think* that the above becomes,
> lyx::pit_type prevpit = boost::prior(pit);
> if (singlepar && prevpit == cursor_[0].pit()) {
> y1 = y - text->getPar(prevpit).descent();
> y2 = y;
> }

No... look again. I added a clarifying comment.

1) You should separately look at singlepar == true and == false, and 
2) the y1, y2 assignments happen only if singlepar == true, and only
   for *one* value of pit.

I improved the BufferView_pimpl.C part of the patch as follows:


Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.595
diff -u -p -r1.595 BufferView_pimpl.C
--- BufferView_pimpl.C  15 Sep 2005 13:55:45 -  1.595
+++ BufferView_pimpl.C  24 Sep 2005 13:01:39 -
@@ -666,12 +666,12 @@ void BufferView::Pimpl::update(Update::f
theCoords.startUpdating();
 
// First drawing step
-   ViewMetricsInfo vi = metrics();
+   ViewMetricsInfo vi = metrics(flags & Update::SinglePar);
bool forceupdate(flags & Update::Force);
 
if ((flags & Update::FitCursor) && fitCursor()) {
forceupdate = true;
-   vi = metrics(flags & Update::SinglePar);
+   vi = metrics();
}
if (forceupdate) {
// Second drawing step
@@ -1327,23 +1327,22 @@ ViewMetricsInfo BufferView::Pimpl::metri
int pit2 = pit;
size_t const npit = text->paragraphs().size();
 
-   lyxerr[Debug::DEBUG]
-<< BOOST_CURRENT_FUNCTION
-<< " npit: " << npit
-<< " pit1: " << pit1
-<< " pit2: " << pit2
-<< endl;
-
-   // Rebreak anchor par
-   text->redoParagraph(pit);
-   int y0 = text->getPar(pit1).ascent() - offset_ref_;
+   // Rebreak anchor paragraph. In Single Paragraph mode, rebreak only
+   // the (main text, not inset!) paragraph containing the cursor.
+   // (if this paragraph contains insets etc., rebreaking will 
+   // recursively descend)
+   if (!singlepar || pit == cursor_.bottom().pit())
+   text->redoParagraph(pit);
+   int y0 = text->getPar(pit).ascent() - offset_ref_;
 
-   // Redo paragraphs above cursor if necessary
+   // Redo paragraphs above anchor if necessary; again, in Single Par
+   // mode, only if we encounter the (main text) one having the cursor.
int y1 = y0;
-   while (!singlepar && y1 > 0 && pit1 > 0) {
+   while (y1 > 0 && pit1 > 0) {
y1 -= text->getPar(pit1).ascent();
--pit1;
-   text->redoParagraph(pit1);
+   if (!singlepar || pit1 == cursor_[0].pit())
+   text->redoParagraph(pit1);
y1 -= text->getPar(pit1).descent();
}
 
@@ -1362,12 +1361,14 @@ ViewMetricsInfo BufferView::Pimpl::metri
anchor_ref_ = 0;
}
 
-   // 

Re: [Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Angus Leeming]

Martin Vermeer wrote:
> I propose to put the attached summarizing patch in, and test and profile
> again.

My comments are those of someone who is entirely ignorant of this part of
the code, so please take them with a pinch of salt. Well meaning
interference :)

Angus


Why the two if statements rather than && ?
Index: BufferView_pimpl.C
-   if ((flags & Update::FitCursor) && fitCursor()) {
-   forceupdate = true;
-   vi = metrics(flags & Update::SinglePar);
+   if (flags & Update::FitCursor) {
+   if (fitCursor()) {
+   forceupdate = true;
+   vi = metrics();
+   }


I think you should comment the code more so that your learning curve
doesn't have to be repeated. How about:
+   // Rebreak the paragraph, but only if the "pit" points to
+   // the bottommost iterator in the cursor stack.
+   // Ie, the paragraph containing all nested insets.
Or something :)
// Rebreak anchor par
-   text->redoParagraph(pit);
-   int y0 = text->getPar(pit1).ascent() - offset_ref_;
+   if (!singlepar || pit == cursor_[0].pit()) // only rebreak cursor para
+   text->redoParagraph(pit);
+   int y0 = text->getPar(pit).ascent() - offset_ref_;


Why does this need to be inside the loop? Looks to me like "y1" and "y2"
are overwritten on each iteration of the loop and that "y" and "pit" are
available immediately afterwards.
@@ -1379,13 +1377,27 @@ ViewMetricsInfo BufferView::Pimpl::metri
for (lyx::pit_type pit = pit1; pit <= pit2; ++pit) {
y += text->getPar(pit).ascent();
theCoords.parPos()[text][pit] = Point(0, y);
+   if (singlepar && pit == cursor_[0].pit()) {
+   // collect cursor paragraph y's
+   y1 = y - text->getPar(pit).ascent();
+   y2 = y + text->getPar(pit).descent();
+   }
y += text->getPar(pit).descent();
}
I *think* that the above becomes,
lyx::pit_type prevpit = boost::prior(pit);
if (singlepar && prevpit == cursor_[0].pit()) {
y1 = y - text->getPar(prevpit).descent();
y2 = y;
}

Re: [Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Andre Poenitz]

On Sat, Sep 24, 2005 at 08:56:58AM +0300, Martin Vermeer wrote:
> BTW am I right in understanding that descending into the cursor stack means
> moving from bottom downward to top (tip?), increasing depth all the time? How
> logical...

Depends on your point of view. Implementation-wise it's certainly
logical to have the tip on top.

> Which do you prefer BTW, .bottom() or [0]?

Bottom. But I don't care much.

Andre'

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Andre Poenitz]

On Thu, Sep 22, 2005 at 09:06:46AM +0200, Lars Gullik Bjønnes wrote:
> | Incidentally, why don't we leave assertions in always? I'd imagine
> | that guaranteed clean up and dumping of foo.lyx.emergency was of huge
> | importance to our users.
> 
> They do quite a lot to the speed...

I'd favour correctness over speed. If a certain single ASSERT is
critical, it should be disabled individually, not all of them.

Andre'

Re: [Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Martin Vermeer]

On Sat, 24 Sep 2005 08:56:58 +0300 (EEST) Martin Vermeer <[EMAIL PROTECTED]>
wrote:

> On Fri, 23 Sep 2005 17:26:48 +0200 Jean-Marc Lasgouttes
> <[EMAIL PROTECTED]> wrote:
> 
> > Martin Vermeer wrote:
> > > I believe the culprit is
> > > 
> > > if (!singlepar || pit1 == cursor_.pit())
> > > 
> > > which I added several times to BufferView_pimpl.C:s metrics method.
> > It
> > > tests for being in the paragraph containing the cursor... but I
> > believe
> > > cursor_.pit() refers to the paragraph iterator _inside_ the inset,
> > when
> > > what we need to have here is the paragraph iterator in the
> > surrounding
> > > text which _contains_ this inset (and the cursor).
> > > 
> > > Anybody know how to do that? cursor_[0].pit() ?
> > 
> > Yes, cursor.pit() is really cursor.top().pit(), so this is the 
> > most-nested cursor slice.
> > 
> > You can also use cursor.bottom().pit() to get the outermost one. But
> > zhy
> > is this the one you need?
> 
> Just a hunch ;-)
> 
> No, seriously: the screen redraw routine renders the paragraph(s) the
> ViewMetricsInfo that the BufferView_pimpl metrics hands it, as _main
> text_
> paragraphs -- recursively descending into any insets it contains. If
> handed an
> inside-inset pit, it will nevertheless interpret it as a main-text pit,
> and
> things will go haywire _in case we are in SinglePar mode_.
> 
> BTW am I right in understanding that descending into the cursor stack
> means
> moving from bottom downward to top (tip?), increasing depth all the
> time? How
> logical...
> 
> Which do you prefer BTW, .bottom() or [0]?
> 
> - Martin


I propose to put the attached summarizing patch in, and test and profile again.

- Martin



Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.595
diff -u -p -r1.595 BufferView_pimpl.C
--- BufferView_pimpl.C	15 Sep 2005 13:55:45 -	1.595
+++ BufferView_pimpl.C	24 Sep 2005 06:10:19 -
@@ -666,12 +666,14 @@ void BufferView::Pimpl::update(Update::f
 		theCoords.startUpdating();
 
 		// First drawing step
-		ViewMetricsInfo vi = metrics();
+		ViewMetricsInfo vi = metrics(flags & Update::SinglePar);
 		bool forceupdate(flags & Update::Force);
 
-		if ((flags & Update::FitCursor) && fitCursor()) {
-			forceupdate = true;
-			vi = metrics(flags & Update::SinglePar);
+		if (flags & Update::FitCursor) {
+			if (fitCursor()) {
+forceupdate = true;
+vi = metrics();
+			}
 		}
 		if (forceupdate) {
 			// Second drawing step
@@ -1327,23 +1329,18 @@ ViewMetricsInfo BufferView::Pimpl::metri
 	int pit2 = pit;
 	size_t const npit = text->paragraphs().size();
 
-	lyxerr[Debug::DEBUG]
-<< BOOST_CURRENT_FUNCTION
-<< " npit: " << npit
-<< " pit1: " << pit1
-<< " pit2: " << pit2
-<< endl;
-
 	// Rebreak anchor par
-	text->redoParagraph(pit);
-	int y0 = text->getPar(pit1).ascent() - offset_ref_;
+	if (!singlepar || pit == cursor_[0].pit()) // only rebreak cursor para
+		text->redoParagraph(pit);
+	int y0 = text->getPar(pit).ascent() - offset_ref_;
 
 	// Redo paragraphs above cursor if necessary
 	int y1 = y0;
-	while (!singlepar && y1 > 0 && pit1 > 0) {
+	while (y1 > 0 && pit1 > 0) {
 		y1 -= text->getPar(pit1).ascent();
 		--pit1;
-		text->redoParagraph(pit1);
+		if (!singlepar || pit1 == cursor_[0].pit())
+			text->redoParagraph(pit1);
 		y1 -= text->getPar(pit1).descent();
 	}
 
@@ -1364,10 +1361,11 @@ ViewMetricsInfo BufferView::Pimpl::metri
 
 	// Redo paragraphs below cursor if necessary
 	int y2 = y0;
-	while (!singlepar && y2 < bv.workHeight() && pit2 < int(npit) - 1) {
+	while (y2 < bv.workHeight() && pit2 < int(npit) - 1) {
 		y2 += text->getPar(pit2).descent();
 		++pit2;
-		text->redoParagraph(pit2);
+		if (!singlepar || pit2 == cursor_[0].pit())
+			text->redoParagraph(pit2);
 		y2 += text->getPar(pit2).ascent();
 	}
 
@@ -1379,13 +1377,27 @@ ViewMetricsInfo BufferView::Pimpl::metri
 	for (lyx::pit_type pit = pit1; pit <= pit2; ++pit) {
 		y += text->getPar(pit).ascent();
 		theCoords.parPos()[text][pit] = Point(0, y);
+		if (singlepar && pit == cursor_[0].pit()) {
+			// collect cursor paragraph y's
+			y1 = y - text->getPar(pit).ascent();
+			y2 = y + text->getPar(pit).descent();
+		}
 		y += text->getPar(pit).descent();
 	}
 
+	if (singlepar) { // collect cursor paragraph iter bounds
+		pit1 = cursor_[0].pit();
+		pit2 = cursor_[0].pit();
+	}
+	
 	lyxerr[Debug::DEBUG]
 << BOOST_CURRENT_FUNCTION
 << " y1: " << y1
 << " y2: " << y2
+<< " pit1: " << pit1
+<< " pit2: " << pit2
+<< " npit: " << npit
+<< " singlepar: " << singlepar
 << endl;
 
 	return ViewMetricsInfo(pit1, pit2, y1, y2, singlepar);
Index: lyxfunc.C
===
RC

Re: [Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Martin Vermeer]

On Fri, 23 Sep 2005 17:26:48 +0200 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> 
wrote:

> Martin Vermeer wrote:
> > I believe the culprit is
> > 
> > if (!singlepar || pit1 == cursor_.pit())
> > 
> > which I added several times to BufferView_pimpl.C:s metrics method.
> It
> > tests for being in the paragraph containing the cursor... but I
> believe
> > cursor_.pit() refers to the paragraph iterator _inside_ the inset,
> when
> > what we need to have here is the paragraph iterator in the
> surrounding
> > text which _contains_ this inset (and the cursor).
> > 
> > Anybody know how to do that? cursor_[0].pit() ?
> 
> Yes, cursor.pit() is really cursor.top().pit(), so this is the 
> most-nested cursor slice.
> 
> You can also use cursor.bottom().pit() to get the outermost one. But
> zhy
> is this the one you need?

Just a hunch ;-)

No, seriously: the screen redraw routine renders the paragraph(s) the
ViewMetricsInfo that the BufferView_pimpl metrics hands it, as _main text_
paragraphs -- recursively descending into any insets it contains. If handed an
inside-inset pit, it will nevertheless interpret it as a main-text pit, and
things will go haywire _in case we are in SinglePar mode_.

BTW am I right in understanding that descending into the cursor stack means
moving from bottom downward to top (tip?), increasing depth all the time? How
logical...

Which do you prefer BTW, .bottom() or [0]?

- Martin

Re: [Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Bennett Helm]

On Sep 23, 2005, at 10:26 AM, Martin Vermeer wrote:


On Fri, 2005-09-23 at 09:07 -0400, Bennett Helm wrote:


On Sep 23, 2005, at 8:59 AM, Bennett Helm wrote:



Cursor movement is a bit strange. This is especially noticeable
with page-up and page-down: it seems like the cursor moves, but the
screen doesn't get redrawn. It also happens with moving the cursor
left and right (though not with up and down) and with moving by
paragraph. The screen does get properly redrawn when moving the
cursor to select text.



Addendum: page-up and page-down *does* redraw the screen, but not the
first time. That is, if you hit page-down, the cursor disappears from
the screen, but nothing else happens; hitting page-down again causes
the screen to redraw to one page down from the start, but the cursor
is still an extra page down off the screen. So it looks like the
screen redraw happens *before* the cursor movement.

Moving cursor left and right does not show this: the screen redraw
just never happens.

Bennett



Thanks Bennett, great testing!

Apply the additional text3.C patch attached, and all should be  
fine ;-)


Yes -- that takes care of the cursor problems.

Bennett

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Bennett Helm]

On Sep 23, 2005, at 10:14 AM, Jean-Marc Lasgouttes wrote:


What happens when you invoke LyX fro, the icon? Are you sure there is
not a gmon.out produced somewhere on your hard disk?


OK -- just me being stupid again. It looks, though, that I've done  
something wrong somewhere, since all the time data come out as 0.0.  
Anyway, here's the complete file:




Bennett

Re: [Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Jean-Marc Lasgouttes]

Martin Vermeer wrote:

I believe the culprit is

if (!singlepar || pit1 == cursor_.pit())

which I added several times to BufferView_pimpl.C:s metrics method. It
tests for being in the paragraph containing the cursor... but I believe
cursor_.pit() refers to the paragraph iterator _inside_ the inset, when
what we need to have here is the paragraph iterator in the surrounding
text which _contains_ this inset (and the cursor).

Anybody know how to do that? cursor_[0].pit() ?


Yes, cursor.pit() is really cursor.top().pit(), so this is the 
most-nested cursor slice.


You can also use cursor.bottom().pit() to get the outermost one. But zhy
is this the one you need?

JMarc

Re: [Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Martin Vermeer]

On Fri, Sep 23, 2005 at 08:59:26AM -0400, Bennett Helm wrote:
> On Sep 22, 2005, at 5:57 PM, Martin Vermeer wrote:

...

> This patch does not help typing in footnotes, TeX Code, or other  
> insets (margin pars, minipages, LyX notes, etc.). Insets within  
> insets work, but are predictably slow as well.

The reason is this in text3.C:

needsUpdate = cur.paragraph().dim().asc != olddim.asc ||
  cur.paragraph().dim().des != olddim.des ||
  cur.paragraph().inInset();<

Was forced to add that, as my new code rendered wrong/not at all with text
inside an inset.

I believe the culprit is

if (!singlepar || pit1 == cursor_.pit())

which I added several times to BufferView_pimpl.C:s metrics method. It
tests for being in the paragraph containing the cursor... but I believe
cursor_.pit() refers to the paragraph iterator _inside_ the inset, when
what we need to have here is the paragraph iterator in the surrounding
text which _contains_ this inset (and the cursor).

Anybody know how to do that? cursor_[0].pit() ?

- Martin



pgpsqAU2TtMui.pgp
Description: PGP signature

Re: [Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Martin Vermeer]

On Fri, 2005-09-23 at 09:07 -0400, Bennett Helm wrote:
> On Sep 23, 2005, at 8:59 AM, Bennett Helm wrote:
> 
> > Cursor movement is a bit strange. This is especially noticeable  
> > with page-up and page-down: it seems like the cursor moves, but the  
> > screen doesn't get redrawn. It also happens with moving the cursor  
> > left and right (though not with up and down) and with moving by  
> > paragraph. The screen does get properly redrawn when moving the  
> > cursor to select text.
> 
> Addendum: page-up and page-down *does* redraw the screen, but not the  
> first time. That is, if you hit page-down, the cursor disappears from  
> the screen, but nothing else happens; hitting page-down again causes  
> the screen to redraw to one page down from the start, but the cursor  
> is still an extra page down off the screen. So it looks like the  
> screen redraw happens *before* the cursor movement.
> 
> Moving cursor left and right does not show this: the screen redraw  
> just never happens.
> 
> Bennett

Thanks Bennett, great testing!

Apply the additional text3.C patch attached, and all should be fine ;-)

- Martin


Index: text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v
retrieving revision 1.307
diff -u -p -r1.307 text3.C
--- text3.C	16 Sep 2005 10:06:09 -	1.307
+++ text3.C	23 Sep 2005 14:21:35 -
@@ -348,6 +348,7 @@ void LyXText::dispatch(LCursor & cur, Fu
 			needsUpdate = cursorLeftOneWord(cur);
 		else
 			needsUpdate = cursorRightOneWord(cur);
+		cur.bv().update(Update::Force | Update::FitCursor);
 		finishChange(cur, false);
 		break;
 
@@ -358,6 +359,7 @@ void LyXText::dispatch(LCursor & cur, Fu
 			needsUpdate = cursorRightOneWord(cur);
 		else
 			needsUpdate = cursorLeftOneWord(cur);
+		cur.bv().update(Update::Force | Update::FitCursor);
 		finishChange(cur, false);
 		break;
 
@@ -419,7 +421,8 @@ void LyXText::dispatch(LCursor & cur, Fu
 && cur.boundary() == oldBoundary) {
 			cur.undispatched();
 			cmd = FuncRequest(LFUN_FINISHED_RIGHT);
-		}
+		} else
+			cur.bv().update(Update::Force | Update::FitCursor);
 		break;
 
 	case LFUN_LEFT:
@@ -435,7 +438,8 @@ void LyXText::dispatch(LCursor & cur, Fu
 			&& cur.boundary() == oldBoundary) {
 			cur.undispatched();
 			cmd = FuncRequest(LFUN_FINISHED_LEFT);
-		}
+		} else
+			cur.bv().update(Update::Force | Update::FitCursor);
 		break;
 
 	case LFUN_UP:
@@ -449,7 +453,8 @@ void LyXText::dispatch(LCursor & cur, Fu
 			  && cur.boundary() == oldBoundary) {
 			cur.undispatched();
 			cmd = FuncRequest(LFUN_FINISHED_UP);
-		}
+		} else
+			cur.bv().update(Update::Force | Update::FitCursor);
 		break;
 
 	case LFUN_DOWN:
@@ -463,13 +468,15 @@ void LyXText::dispatch(LCursor & cur, Fu
 		{
 			cur.undispatched();
 			cmd = FuncRequest(LFUN_FINISHED_DOWN);
-		}
+		} else
+			cur.bv().update(Update::Force | Update::FitCursor);
 		break;
 
 	case LFUN_UP_PARAGRAPH:
 		if (!cur.mark())
 			cur.clearSelection();
 		needsUpdate = cursorUpParagraph(cur);
+		cur.bv().update(Update::Force | Update::FitCursor);
 		finishChange(cur, false);
 		break;
 
@@ -484,6 +491,7 @@ void LyXText::dispatch(LCursor & cur, Fu
 		if (!cur.mark())
 			cur.clearSelection();
 		needsUpdate = cursorDownParagraph(cur);
+		cur.bv().update(Update::Force | Update::FitCursor);
 		finishChange(cur, false);
 		break;
 
@@ -562,6 +570,7 @@ void LyXText::dispatch(LCursor & cur, Fu
 			cmd = FuncRequest(LFUN_FINISHED_UP);
 		} else {
 			needsUpdate = cursorPrevious(cur);
+		cur.bv().update(Update::Force | Update::FitCursor);
 		}
 		break;
 
@@ -576,6 +585,7 @@ void LyXText::dispatch(LCursor & cur, Fu
 			cmd = FuncRequest(LFUN_FINISHED_DOWN);
 		} else {
 			needsUpdate = cursorNext(cur);
+		cur.bv().update(Update::Force | Update::FitCursor);
 		}
 		break;



signature.asc
Description: This is a digitally signed message part

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Jean-Marc Lasgouttes]

Angus Leeming wrote:

Linking here takes over an hour with Debian unstable's gcc 4.0.2, ld
2.16, so I'm not really in a position to do too much experimentation.
However, there's no reason why you couldn't generate a similar
profiling executable using the configure command that I posted.
Presumably, linking times for you will be much shorter if you're
using gcc < 4.


Angus, as far as I know it is possible to run gprof on a binary that 
does not have debug info. All you loose is the line numbers and such 
niceties.


JMarc

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Jean-Marc Lasgouttes]

> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:

Bennett> OK ... I've tried this, and it looks like
Bennett> --disable-assertions creates problems requiring that

Bennett> #include 

Bennett> be added to each of the following:

Bennett> src/factory.C src/messages.C src/text.C src/text2.C

Indeed, I'll fix this.

Bennett> Unfortunately, I can't get profiling to be usable: starting
Bennett> LyX from the command line on Mac results in a LyX window that
Bennett> refuses to take focus (resulting in useless profiling info),
Bennett> and I can't figure out any other way to produce gmon.out.
Bennett> (Any suggestions?)

What happens when you invoke LyX fro, the icon? Are you sure there is
not a gmon.out produced somewhere on your hard disk?

JMarc

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Bennett Helm]

On Sep 22, 2005, at 3:57 AM, Jean-Marc Lasgouttes wrote:


Angus> It looks like we're all seeing the same thing. Time to do some
Angus> profiling I guess. If someone gives me a prescription of what I
Angus> need to do to recompile lyx ready for profiling and how to use
Angus> gprof, I'll volunteer.

We have a --enable-profiling option nowadays. Note that it is not
enough in itself. You should add
  --disable-assertions --disable-stdlib-debug -enable-optimization=-O2


OK ... I've tried this, and it looks like --disable-assertions  
creates problems requiring that


#include 

be added to each of the following:

src/factory.C
src/messages.C
src/text.C
src/text2.C


(I also had to hand-edit the tex2lyx Makefile to change optimization  
to -Os, because of an apparent gcc bug on Mac OS X with -O2.)


Unfortunately, I can't get profiling to be usable: starting LyX from  
the command line on Mac results in a LyX window that refuses to take  
focus (resulting in useless profiling info), and I can't figure out  
any other way to produce gmon.out. (Any suggestions?)


Bennett

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Martin Vermeer]

On Fri, 2005-09-23 at 13:56 +0100, Angus Leeming wrote:
> Martin Vermeer wrote:
> >> Attached are edited highlights from this profiling. There would
> >> appear to be lots of scope for improvement :)
> >> 
> >> Assuming that I'm editing the right bit of the profile log of
> >> course...
> 
> > I think it is. And it is precisely the things my patch addresses...
> > BufferView-pimpl-update, lyxtext-redoParagraph, screen-redraw and
> > all that stuff.
> 
> Linking here takes over an hour with Debian unstable's gcc 4.0.2, ld
> 2.16, so I'm not really in a position to do too much experimentation.
> However, there's no reason why you couldn't generate a similar
> profiling executable using the configure command that I posted.
> Presumably, linking times for you will be much shorter if you're
> using gcc < 4.
> 
> Given Helge's reports on improved behaviour with your patch, I'd
> anticipate that it, or something like it, will go into the tree soon.
> Thereafter, I'll generate a new executable and post a new report if
> nobody beats me to it.
> 
> > Except 
> > QContentPane::keyeventTimeout()
> > which we should still look at separately then:
> > // Restart the timer.
> > step_timer_.start(25, true);
> > If this is the timer in milliseconds, perhaps we should see what
> > happens if we raise it to 50.
> 
> int QTimer::start ( int msec, bool sshot = FALSE )
> 
> Starts the timer with a msec milliseconds timeout, and returns the ID
> of the timer, or zero when starting the timer failed.
> 
> If sshot is TRUE, the timer will be activated only once; otherwise it
> will continue until it is stopped.
> 
> Any pending timer will be stopped.

 connect(&step_timer_, SIGNAL(timeout()), SLOT(keyeventTimeout()));

So when it times out, it is restarted... as it says in the comment. The
idea behind this was at the time, that there would never be more than
one "unserviced" timer running even during congestion, as would happen
with a repeat timer.


> Anyway, "cvs annotate" is blaming you for this code :)
> 
> 1.35  (vermeer  06-Jun-05):
> 1.35  (vermeer  06-Jun-05):  // Start the timer, one-shot.
> 1.35  (vermeer  06-Jun-05):  step_timer_.start(25, true);
> 
> Diff to previous 1.34
> Lars's key input queue

Yes... he tricked me into that :)

- Martin


signature.asc
Description: This is a digitally signed message part

Re: [Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Bennett Helm]

On Sep 23, 2005, at 8:59 AM, Bennett Helm wrote:

Cursor movement is a bit strange. This is especially noticeable  
with page-up and page-down: it seems like the cursor moves, but the  
screen doesn't get redrawn. It also happens with moving the cursor  
left and right (though not with up and down) and with moving by  
paragraph. The screen does get properly redrawn when moving the  
cursor to select text.


Addendum: page-up and page-down *does* redraw the screen, but not the  
first time. That is, if you hit page-down, the cursor disappears from  
the screen, but nothing else happens; hitting page-down again causes  
the screen to redraw to one page down from the start, but the cursor  
is still an extra page down off the screen. So it looks like the  
screen redraw happens *before* the cursor movement.


Moving cursor left and right does not show this: the screen redraw  
just never happens.


Bennett

Re: [Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Bennett Helm]

On Sep 22, 2005, at 5:57 PM, Martin Vermeer wrote:


Give the attached a try.

I think it is quite a bit faster, and fixes your noticed side effect.


Wow! What a difference! Typing in long documents feels almost as fast  
as 1.3.6, and processor usage no longer gets pegged at absurdly high  
levels. The side effect is fixed as well.



There may be other side effects; this patch touches so many things, it
scares me a bit. But the speedup is so substantial that perhaps we
should just take the jump, and clean up afterwards. And I have a good
feeling that now SinglePar works as it was intended to.


This patch does not help typing in footnotes, TeX Code, or other  
insets (margin pars, minipages, LyX notes, etc.). Insets within  
insets work, but are predictably slow as well.


Cut and paste works, as does undo. (Undo even works when the previous  
change was off the current screen: the screen is properly redrawn at  
the location of the last change.)


Cursor movement is a bit strange. This is especially noticeable with  
page-up and page-down: it seems like the cursor moves, but the screen  
doesn't get redrawn. It also happens with moving the cursor left and  
right (though not with up and down) and with moving by paragraph. The  
screen does get properly redrawn when moving the cursor to select text.


One final (and minor) oddity I've noticed: quick, repeated deleting  
of previous words results in the cursor moving backwards faster than  
the words get erased from the screen.


Bennett

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Angus Leeming]

Martin Vermeer wrote:
>> Attached are edited highlights from this profiling. There would
>> appear to be lots of scope for improvement :)
>> 
>> Assuming that I'm editing the right bit of the profile log of
>> course...

> I think it is. And it is precisely the things my patch addresses...
> BufferView-pimpl-update, lyxtext-redoParagraph, screen-redraw and
> all that stuff.

Linking here takes over an hour with Debian unstable's gcc 4.0.2, ld
2.16, so I'm not really in a position to do too much experimentation.
However, there's no reason why you couldn't generate a similar
profiling executable using the configure command that I posted.
Presumably, linking times for you will be much shorter if you're
using gcc < 4.

Given Helge's reports on improved behaviour with your patch, I'd
anticipate that it, or something like it, will go into the tree soon.
Thereafter, I'll generate a new executable and post a new report if
nobody beats me to it.

> Except 
> QContentPane::keyeventTimeout()
> which we should still look at separately then:
> // Restart the timer.
> step_timer_.start(25, true);
> If this is the timer in milliseconds, perhaps we should see what
> happens if we raise it to 50.

int QTimer::start ( int msec, bool sshot = FALSE )

Starts the timer with a msec milliseconds timeout, and returns the ID
of the timer, or zero when starting the timer failed.

If sshot is TRUE, the timer will be activated only once; otherwise it
will continue until it is stopped.

Any pending timer will be stopped.


Anyway, "cvs annotate" is blaming you for this code :)

1.35  (vermeer  06-Jun-05):
1.35  (vermeer  06-Jun-05):  // Start the timer, one-shot.
1.35  (vermeer  06-Jun-05):  step_timer_.start(25, true);

Diff to previous 1.34
Lars's key input queue

RCS file: /home/lyx/cvs/lyx-devel/src/frontends/qt2/QContentPane.C,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- lyx-devel/src/frontends/qt2/QContentPane.C2005/06/03 09:25:46   
1.34
+++ lyx-devel/src/frontends/qt2/QContentPane.C2005/06/06 12:34:28   
1.35
@@ -19,7 +19,6 @@
 
 #include 
 #include 
-#include 
 
 #include 
 
@@ -90,6 +89,8 @@
 boost::bind(&QContentPane::generateSyntheticMouseEvent,
 this));
 
+connect(&step_timer_, SIGNAL(timeout()),
SLOT(keyeventTimeout()));
+
 setFocusPolicy(QWidget::WheelFocus);
 setFocus();
 setCursor(ibeamCursor);
@@ -101,6 +102,9 @@
 // stupid moc strikes again
 connect(wa_->scrollbar_, SIGNAL(valueChanged(int)),
 this, SLOT(scrollBarChanged(int)));
+
+// Start the timer, one-shot.
+step_timer_.start(25, true);
 }
 
 
@@ -251,9 +255,35 @@
 
 void QContentPane::keyPressEvent(QKeyEvent * e)
 {
+keyeventQueue_.push(boost::shared_ptr(new
QKeyEvent(*e)));
+}
+
+
+void QContentPane::keyeventTimeout()
+{
+bool handle_autos = true;
+
+while (!keyeventQueue_.empty()) {
+boost::shared_ptr ev = keyeventQueue_.front();
+
+// We never handle more than one auto repeated
+// char in a list of queued up events.
+if (!handle_autos && ev->isAutoRepeat()) {
+keyeventQueue_.pop();
+continue;
+}
+
 boost::shared_ptr sym(new QLyXKeySym);
-sym->set(e);
-wa_->workAreaKeyPress(sym, q_key_state(e->state()));
+sym->set(ev.get());
+
+wa_->workAreaKeyPress(sym, q_key_state(ev->state()));
+keyeventQueue_.pop();
+
+handle_autos = false;
+}
+
+// Restart the timer.
+step_timer_.start(25, true);
 }


-- 
Angus

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Martin Vermeer]

On Fri, 2005-09-23 at 11:05 +0100, Angus Leeming wrote:
> Angus Leeming wrote:

...

> Attached are edited highlights from this profiling. There would appear
> to be lots of scope for improvement :)
> 
> Assuming that I'm editing the right bit of the profile log of
> course...
> 
> -- 
> Angus

I think it is. And it is precisely the things my patch addresses...
BufferView-pimpl-update, lyxtext-redoParagraph, screen-redraw and all
that stuff. Except

QContentPane::keyeventTimeout()

which we should still look at separately then:

// Restart the timer.
step_timer_.start(25, true);

If this is the timer in milliseconds, perhaps we should see what happens
if we raise it to 50.

- Martin



signature.asc
Description: This is a digitally signed message part

Re: [Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Helge Hafting]

Martin Vermeer wrote:


On Fri, 2005-09-23 at 08:58 +0200, Helge Hafting wrote:
 


Martin Vermeer wrote:

   


Give the attached a try.

I think it is quite a bit faster, and fixes your noticed side effect. 


There may be other side effects; this patch touches so many things, it
scares me a bit. But the speedup is so substantial that perhaps we
should just take the jump, and clean up afterwards. And I have a good
feeling that now SinglePar works as it was intended to.


 


I tried the patch and saw no problems with it. Moving around and
editing a document with lots of short paragraphs works very well,
I can't force a load spike.

The crazy 100k paragraph improved too, although I can still
type faster than lyx in this case.  Scrolling to the bottom with the
"page down" key wasn't painful this time though - a clear improvement.

Opening a 30-page real document worked fine too, I could scroll through
it very fast with either pagedown or scrollbar.  Great speed, and no
load spike.

Helge Hafting
   



Thanks Helge! This is good news.

Did you try any out-of-the-ordinary things? Different types of insets,
insets-within-insets, cut/paste, undo, ... 
 


That attempt was only opening the document, and writing some text.
I also scrolled through that 30-page document which contains
some graphichs, tables bullet lists, sectioning and a TOC.

Now I tried making a new document, paste in chapters from
the user guide, and modify them.  A deeply nested list
with enumerations and bullets worked well.

A table oddity:  mark several  cells, turn them all bold in one go,
undo undoes bold in one cell at a time. (I.e. undo,undo,undo...)
in order to undo all of it. The display is correct through all of this,
but it'd be nice if I could undo everything with the same ease
as _doing_ it.  (Well, I can by marking it and un-bolding it.)

Changed the amount of vertical spacing in a vert. spacing inset,
"undo" did not undo that, instead one more bold table cell
was undone.  Vertical inset editing isn't registered with the
undo mechanism?  I'll write a separate bug report on that.

Stuck a box in a table, a nested bullet/enumerated list in that,
a table in that, a box inside that again.  Copied the entire
outer box into some other table cell. No problems.

Undo crash: Entered some math:
1+"Normal text"
--
 _

Cut the "+", try to insert it in the denominator (nothing happens)
Undo does nothing
Undo does nothing
Undo crashes lyx:
 pasteSelection 0
### should be handled in MathNest/GridInset
cutSelection in mathed
copySelection in mathed
 pasteSelection 0
### should be handled in MathNest/GridInset
 pasteSelection 0
### should be handled in MathNest/GridInset
action: 12
action: 12
action: 12
DocIterator StableDocIterator::asDocIterator(InsetBase*) const Should 
not happen

, but does e.g. after C-n C-l C-z S-C-z
dit:  inset: 0x8ab35d4 idx: 0 par: 117 pos: 0
inset: 0x8abcdd0 idx: 0 par: 0 pos: 0
inset: 0x8e16288 idx: 0 par: 0 pos: 2

lastpos: 2
Assertion triggered in DocIterator StableDocIterator::asDocIterator

I guess this wasn't related to the display speedup? I saw no
display peculiarities at all.

Helge Hafting

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Angus Leeming]

Angus Leeming wrote:

> Angus Leeming wrote:
>> $ ../configure \
>> --enable-profiling \
>> --disable-assertions \
>> --disable-stdlib-debug \
>> --enable-optimization=-O2 \
>> --with-frontend='qt' --with-qt-includes='/usr/include/qt3' \
>> LDFLAGS='-Wl,-t'
> 
> OK, Jean-Marc, Georg.
> The thing took over an hour to link but it works. I fired up LyX,
> opened up an old document and typed garbage in the first paragraph
> faster than LyX could keep up. Then I quit LyX.
> 
> You can find the resulting output of
>   $ gprof ./lyx-qt > profile.txt
> here:
>   http://www.lyx.org/~leeming/profile.txt.bz2
> (209kB expanding to 4.1MB)
> 
> Does it help any?
> 
> Angus
> 
> ps, this is pristine CVS. I haven't tried out Martin's patches. I'm
> perfectly happy to do so, but would like someone to take me through
> the output first :)

Attached are edited highlights from this profiling. There would appear
to be lots of scope for improvement :)

Assuming that I'm editing the right bit of the profile log of
course...

-- 
Angusindex % timeself  childrencalled name
[1] 75.50.001.01 153+506  [1]
0.000.94  74 BufferView::Pimpl::update(Update::flags)  [2]
0.000.05   2 BufferView::Pimpl::setBuffer(Buffer*)  [73]
[2] 70.50.000.94  74 BufferView::Pimpl::update(Update::flags)  [2]
0.000.59  72/72  BufferView::Pimpl::metrics(bool) [6]
0.000.28  39/39  LyXScreen::redraw(BufferView&, ViewMetricsInfo const&) [21]
0.000.04  72/72  Buffer::buildMacros() [80]
---
[3] 53.00.010.70 869 LyXText::redoParagraph(long) [3]
0.000.271248/1248MathHullInset::metrics(MetricsInfo&, Dimension&) const [27]
0.000.20 476/476 MathMacroTemplate::metrics(MetricsInfo&, Dimension&) const [33]
0.020.072561/2561LyXText::rowBreakPoint(long, Row&) const [59]
0.010.062561/2561LyXText::setRowWidth(long, Row&) const [66]
0.010.052561/2561LyXText::setHeightOfRow(long, Row&) [71]
0.000.011724/8045LyXText::leftMargin(long, long) const [89]
---
[4] 46.40.000.62  34 LyXFunc::dispatch(FuncRequest const&) [4]
0.000.26  32/34  LCursor::dispatch(FuncRequest const&) [23]
0.000.22  33/65  BufferView::update(Update::flags) [17]
0.000.13   1/1   LyXFunc::open(std::string const&) [40]
0.000.01   1/1   QuitLyX(bool) [208]
0.000.01  32/32  Buffer::markDirty() [261]
---
[5] 46.20.000.62 QContentPane::qt_invoke(int, QUObject*) [5]
0.000.591077/1077QContentPane::keyeventTimeout() [7]
0.000.03   8/8   QContentPane::scrollBarChanged(int) [109]
---
0.000.59  72/72  BufferView::Pimpl::update(Update::flags)  [2]
[6] 44.40.000.59  72 BufferView::Pimpl::metrics(bool) [6]
0.000.59 725/869 LyXText::redoParagraph(long) [3]
---
[7] 44.00.000.591077 QContentPane::keyeventTimeout() [7]
0.000.59  32/32  boost::signal2, key_modifier::state, boost::last_value, int, std::less, boost::function, key_modifier::state), std::allocator > >::operator()(boost::shared_ptr, key_modifier::state) [8]
id>, int, std::less, boost::function, key_modifier::state), std::allocator > >::operator()(boost::shared_ptr, key_modifier::state) [8]
0.000.59  32/32  boost::detail::postfix_increment_result::caller, key_modifier::state, boost::function, key_modifier::state), std::allocator > >, boost::signals::detail::named_slot_map_iterator>, boost::signals::detail::unusable, boost::signals::detail::unusable const&, boost::single_pass_traversal_tag>::type boost::operator++::caller, key_modifier::state, boost::function, key_modifier::state), std::allocator > >, boost::signals::detail::named_slot_map_iterator>, boost::signals::detail::unusable, boost::single_pass_traversal_tag, boost::signals::detail::unusable const&, long>(boost::iterator_facade::caller, key_modifier::state, boost::function, key_modifier::state), std::allocator > >, boost::signals::detail::named_slot_map_iterator>, boost::signals::detail::unusable, boost::single_pass_traversal_tag, boost::signals::detail::unusable const&, long>&, int) [9]
---

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Angus Leeming]

Angus Leeming wrote:
> $ ../configure \
> --enable-profiling \
> --disable-assertions \
> --disable-stdlib-debug \
> --enable-optimization=-O2 \
> --with-frontend='qt' --with-qt-includes='/usr/include/qt3' \
> LDFLAGS='-Wl,-t'

OK, Jean-Marc, Georg.
The thing took over an hour to link but it works. I fired up LyX,
opened up an old document and typed garbage in the first paragraph
faster than LyX could keep up. Then I quit LyX.

You can find the resulting output of
  $ gprof ./lyx-qt > profile.txt
here:
  http://www.lyx.org/~leeming/profile.txt.bz2
(209kB expanding to 4.1MB)

Does it help any?

Angus

ps, this is pristine CVS. I haven't tried out Martin's patches. I'm
perfectly happy to do so, but would like someone to take me through
the output first :)

-- 
Angus

Re: [Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Martin Vermeer]

On Fri, 2005-09-23 at 08:58 +0200, Helge Hafting wrote:
> Martin Vermeer wrote:
> 
> >Give the attached a try.
> >
> >I think it is quite a bit faster, and fixes your noticed side effect. 
> >
> >There may be other side effects; this patch touches so many things, it
> >scares me a bit. But the speedup is so substantial that perhaps we
> >should just take the jump, and clean up afterwards. And I have a good
> >feeling that now SinglePar works as it was intended to.
> >  
> >
> I tried the patch and saw no problems with it. Moving around and
> editing a document with lots of short paragraphs works very well,
> I can't force a load spike.
> 
> The crazy 100k paragraph improved too, although I can still
> type faster than lyx in this case.  Scrolling to the bottom with the
> "page down" key wasn't painful this time though - a clear improvement.
> 
> Opening a 30-page real document worked fine too, I could scroll through
> it very fast with either pagedown or scrollbar.  Great speed, and no
> load spike.
> 
> Helge Hafting

Thanks Helge! This is good news.

Did you try any out-of-the-ordinary things? Different types of insets,
insets-within-insets, cut/paste, undo, ... 

Mac people?

- Martin



signature.asc
Description: This is a digitally signed message part

Re: [Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Helge Hafting]

Martin Vermeer wrote:


Give the attached a try.

I think it is quite a bit faster, and fixes your noticed side effect. 


There may be other side effects; this patch touches so many things, it
scares me a bit. But the speedup is so substantial that perhaps we
should just take the jump, and clean up afterwards. And I have a good
feeling that now SinglePar works as it was intended to.
 


I tried the patch and saw no problems with it. Moving around and
editing a document with lots of short paragraphs works very well,
I can't force a load spike.

The crazy 100k paragraph improved too, although I can still
type faster than lyx in this case.  Scrolling to the bottom with the
"page down" key wasn't painful this time though - a clear improvement.

Opening a 30-page real document worked fine too, I could scroll through
it very fast with either pagedown or scrollbar.  Great speed, and no
load spike.

Helge Hafting

Re: [Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Martin Vermeer]

On Thu, Sep 22, 2005 at 09:21:31AM -0400, Bennett Helm wrote:
> On Sep 22, 2005, at 4:08 AM, Martin Vermeer wrote:
> 
> >Here is a better patch, taking care of rowpainter too. metrics is  
> >still
> >called twice, but now (generally) only for the current paragraph, not
> >the whole screen. Ought to be faster.
> >
> >I saw no side effects.
> 
> I tried it, and it generally feels quite a bit faster, though there  
> still is considerable lag.
> 
> I did notice a side effect: typing in one paragraph causes text in  
> the paragraph after the next paragraph to be poorly displayed. At  
> first, it looks as though all text in that later paragraph is being  
> displayed one pixel over on top of the previous text (giving the  
> impression of boldface). As I continue typing, text in that paragraph  
> keeps getting displayed progressively further to the right (so that  
> it gradually looks bolder and bolder). Then, when my typing causes a  
> new line to be displayed, the text in that later paragraph is redrawn  
> without erasing the previous text, resulting in the screen shot I've  
> attached.
> 
> The text in that paragraph gets redrawn with a mouse click. But  
> there's a further problem: although clicking above the badly drawn  
> paragraph places the cursor in the right place, clicking below it  
> places the cursor in the last line of the badly drawn paragraph.
> 
> Bennett

Give the attached a try.

I think it is quite a bit faster, and fixes your noticed side effect. 

There may be other side effects; this patch touches so many things, it
scares me a bit. But the speedup is so substantial that perhaps we
should just take the jump, and clean up afterwards. And I have a good
feeling that now SinglePar works as it was intended to.

- Martin

Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.595
diff -u -p -r1.595 BufferView_pimpl.C
--- BufferView_pimpl.C  15 Sep 2005 13:55:45 -  1.595
+++ BufferView_pimpl.C  22 Sep 2005 21:47:03 -
@@ -666,12 +666,14 @@ void BufferView::Pimpl::update(Update::f
theCoords.startUpdating();
 
// First drawing step
-   ViewMetricsInfo vi = metrics();
+   ViewMetricsInfo vi = metrics(flags & Update::SinglePar);
bool forceupdate(flags & Update::Force);
 
-   if ((flags & Update::FitCursor) && fitCursor()) {
-   forceupdate = true;
-   vi = metrics(flags & Update::SinglePar);
+   if (flags & Update::FitCursor) {
+   if (fitCursor()) {
+   forceupdate = true;
+   vi = metrics();
+   }
}
if (forceupdate) {
// Second drawing step
@@ -1327,23 +1329,18 @@ ViewMetricsInfo BufferView::Pimpl::metri
int pit2 = pit;
size_t const npit = text->paragraphs().size();
 
-   lyxerr[Debug::DEBUG]
-<< BOOST_CURRENT_FUNCTION
-<< " npit: " << npit
-<< " pit1: " << pit1
-<< " pit2: " << pit2
-<< endl;
-
// Rebreak anchor par
-   text->redoParagraph(pit);
-   int y0 = text->getPar(pit1).ascent() - offset_ref_;
+   if (!singlepar || pit == cursor_.pit()) // only rebreak cursor para
+   text->redoParagraph(pit);
+   int y0 = text->getPar(pit).ascent() - offset_ref_;
 
// Redo paragraphs above cursor if necessary
int y1 = y0;
-   while (!singlepar && y1 > 0 && pit1 > 0) {
+   while (y1 > 0 && pit1 > 0) {
y1 -= text->getPar(pit1).ascent();
--pit1;
-   text->redoParagraph(pit1);
+   if (!singlepar || pit1 == cursor_.pit())
+   text->redoParagraph(pit1);
y1 -= text->getPar(pit1).descent();
}
 
@@ -1364,10 +1361,11 @@ ViewMetricsInfo BufferView::Pimpl::metri
 
// Redo paragraphs below cursor if necessary
int y2 = y0;
-   while (!singlepar && y2 < bv.workHeight() && pit2 < int(npit) - 1) {
+   while (y2 < bv.workHeight() && pit2 < int(npit) - 1) {
y2 += text->getPar(pit2).descent();
++pit2;
-   text->redoParagraph(pit2);
+   if (!singlepar || pit2 == cursor_.pit())
+   text->redoParagraph(pit2);
y2 += text->getPar(pit2).ascent();
}
 
@@ -1379,13 +1377,27 @@ ViewMetricsInfo BufferView::Pimpl::metri
for (lyx::pit_type pit = pit1; pit <= pit2; ++pit) {
y += text->getPar(pit).ascent();
theCoords.parPos()[text][pit] = Point(0, y);
+   if (singlepar && pit == cursor_.pit()) {
+   // collect cursor paragraph y's
+   y1 = y 

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| 
| | Lars, stdlib-debug is currently enabled for prereleases. Could we at 
| | least disable that? A prerelease should be compiled in the same 
| | conditions as a real release...
| 
| Lars> Or almost... leave assertions in f.ex.
| 
| So, would the following patch be OK?

Ok wiht me.

-- 
Lgb

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Angus Leeming]

Jean-Marc Lasgouttes wrote:
> We have a --enable-profiling option nowadays. Note that it is not
> enough in itself. You should add
>   --disable-assertions --disable-stdlib-debug
>   -enable-optimization=-O2
> 
> The big problem with gprof is that I never manage to get it to count
> the time spent in the Qt library. That makes its timings pretty
> useless in the case we are interesting in.

I don't think so. LyX feels the same to me running with either
frontend. Anyway, I'm currently building now, having configured, so.
Look OK?

$ ../configure \
--enable-profiling \
--disable-assertions \
--disable-stdlib-debug \
--enable-optimization=-O2 \
--with-frontend='qt' --with-qt-includes='/usr/include/qt3' \
LDFLAGS='-Wl,-t'

I've hisotorically needed the LDFLAGS to overcome a linker bug that
leads to errors:
chset.o(.rodata+0x8): relocation truncated to fit: GPREL32 UND

Dunno if I still need it...

Configuration
  Host type:  alphaev6-unknown-linux-gnu
  Special build flags:compression aiksaurus pch
concept-checks warnings  use-aspell use-ispell
  C   Compiler:   gcc
  C   Compiler LyX flags:
  C   Compiler flags: -Wextra -Wall   
-I/usr/X11R6/include -pg -g -O2
  C++ Compiler:   g++ (4.0.2)
  C++ Compiler LyX flags:  -fno-exceptions
  C++ Compiler flags: -Wextra -Wall   
-I/usr/X11R6/include -pg -g -O2
  Linker flags:
  Linker user flags:  -pg -Wl,-t
  Qt Frontend:
  Qt version:   3.3.5
  Packaging:  posix
  LyX binary dir: /usr/local/bin
  LyX files dir:  /usr/local/share/lyx

> It is supposedly possible to use oprofile to get a nice system-wide
> profile, and call-graph can be obtained with a really recent kernel
> (2.6.12?). This would be the best solution, I guess.

I'll try gprof first. The Alpha has a 2.4 kernel which means I'd have
to rebuild it to give me oprofile support, if I understand the
oprofile docs correctly.

-- 
Angus

Re: [Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Bennett Helm]

On Sep 22, 2005, at 4:08 AM, Martin Vermeer wrote:

Here is a better patch, taking care of rowpainter too. metrics is  
still

called twice, but now (generally) only for the current paragraph, not
the whole screen. Ought to be faster.

I saw no side effects.


I tried it, and it generally feels quite a bit faster, though there  
still is considerable lag.


I did notice a side effect: typing in one paragraph causes text in  
the paragraph after the next paragraph to be poorly displayed. At  
first, it looks as though all text in that later paragraph is being  
displayed one pixel over on top of the previous text (giving the  
impression of boldface). As I continue typing, text in that paragraph  
keeps getting displayed progressively further to the right (so that  
it gradually looks bolder and bolder). Then, when my typing causes a  
new line to be displayed, the text in that later paragraph is redrawn  
without erasing the previous text, resulting in the screen shot I've  
attached.


The text in that paragraph gets redrawn with a mouse click. But  
there's a further problem: although clicking above the badly drawn  
paragraph places the cursor in the right place, clicking below it  
places the cursor in the last line of the badly drawn paragraph.


Bennett

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Helge Hafting]

Martin Vermeer wrote:


On Thu, 2005-09-22 at 11:09 +0200, Alfredo Braunstein wrote:
 



I'll get around to test it eventually ;-) Lately I'm slower than the qt
frontend.

Alfredo
   



Do you see the slowness in measurable form? I think it's really the Mac
people that should test this.
 


Typing ahead of lyx is not a mac-only problem.  Try creating
a paragraph that fills the lyx window twice. (The default window
size lyx starts with.) If I type garbage, I can be more than a line ahead
with a 2.4GHz pentium.  This paragraph size isn't "unreasonable".
Your patch helps this case, but:

An "unreasonable" 100k paragraph is a pain to write in with
lyx 1.4 cvs.  But try lyx 1.3, and it edits the big paragraph as
effortlessly as a half-page document. I can't out-type it or
even create a load spike typing in garbage.  And the scrollbar
works as expected too.  I'll still be using lyx 1.4 for its
many nice features, but hope any performance-related patches
will go in despite the freeze.

Helge Hafting

Re: [Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Helge Hafting]

Martin Vermeer wrote:


On Thu, 2005-09-22 at 03:26 +0300, Martin Vermeer wrote:


 


I also noted that metrics is called twice for every keystroke. Surely one of
those isn't necessary.

Sounds reasonable? Please test. Is it faster, or is it my imagination?
   



Here is a better patch, taking care of rowpainter too. metrics is still
called twice, but now (generally) only for the current paragraph, not
the whole screen. Ought to be faster. 


I saw no side effects.
 


The patch seems to have no ill effects.  It seems to improve things
on my linux pc, but:

My pathological 125k test paragraph is a paint to edit, with or without
the patch.  I haven't tested at the end, because attempts to scroll
there is no fun either.  Of course nobody should write such paragraphs . . .

My 45k test text with lots of small paragrahps have ok performance
either way.  Still, I hope performance patches like this goes in. Many
machines are weaker the one I tested on.

Helge Hafting

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Alfredo Braunstein]

Martin Vermeer wrote:

> Do you see the slowness in measurable form? I think it's really the Mac

I do. I cannot do half the stuff I used to. ;-)

> people that should test this.

I was talking about me, not lyx. 

Still, I don't see why does the slowness would apply to Macs specifically.
(and Angus' report was on linux IIRC)

Alfredo

PS: sorry the people who are receiving duplicates. I keep pushing the wrong
button. Arghh...  I think I've forgot how to use a computer and I'll have
to downgrade to a typewriter. ;-)

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Martin Vermeer]

On Thu, 2005-09-22 at 11:09 +0200, Alfredo Braunstein wrote:
> Martin Vermeer wrote:
> 
> > That's part of the story. Another part is that a long long time ago, I
> > tried to implement a thing called Update::SinglePar. The idea was that, as
> > long as a paragraph's metrics don't change, you can type into it and _only
> > it_ will be updated.
> 
> Ok. Note that I was referring only to the fact that short paragraphs seemed
> to be faster, even if the same amout of text was onscreen.
> But I agree with you in that clean self-contained optimizations are the way
> out.
> 
> 
> > That's the theory. Unfortunately, what is in CVS doesn't actually do this.
> > Still the whole screen gets updated, always, with rebreaking for every
> > paragraph. The singlepar code in metrics isn't actually used. My bad.
> 
> Ah ok. 
>  
> > I tried the following modification, to make this stuff (1) work, and (2)
> > work correctly as intended:
> 
> > Sounds reasonable? Please test. Is it faster, or is it my imagination?
> 
> I'll get around to test it eventually ;-) Lately I'm slower than the qt
> frontend.
> 
> Alfredo

Do you see the slowness in measurable form? I think it's really the Mac
people that should test this.

- Martin



signature.asc
Description: This is a digitally signed message part

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Alfredo Braunstein]

Martin Vermeer wrote:

> That's part of the story. Another part is that a long long time ago, I
> tried to implement a thing called Update::SinglePar. The idea was that, as
> long as a paragraph's metrics don't change, you can type into it and _only
> it_ will be updated.

Ok. Note that I was referring only to the fact that short paragraphs seemed
to be faster, even if the same amout of text was onscreen.
But I agree with you in that clean self-contained optimizations are the way
out.


> That's the theory. Unfortunately, what is in CVS doesn't actually do this.
> Still the whole screen gets updated, always, with rebreaking for every
> paragraph. The singlepar code in metrics isn't actually used. My bad.

Ah ok. 
 
> I tried the following modification, to make this stuff (1) work, and (2)
> work correctly as intended:

> Sounds reasonable? Please test. Is it faster, or is it my imagination?

I'll get around to test it eventually ;-) Lately I'm slower than the qt
frontend.

Alfredo

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Alfredo Braunstein]

> Hi, Alfredo! Hope you and yours are all well.

Hi Angus! Long time no read ;-) We're doing fine I think. Learning a lot
every day ;-)

Alfredo

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

| Lars, stdlib-debug is currently enabled for prereleases. Could we at 
| least disable that? A prerelease should be compiled in the same 
| conditions as a real release...

Lars> Or almost... leave assertions in f.ex.

So, would the following patch be OK?

JMarc

Index: config/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/config/ChangeLog,v
retrieving revision 1.173
diff -u -p -r1.173 ChangeLog
--- config/ChangeLog	8 Sep 2005 09:20:12 -	1.173
+++ config/ChangeLog	22 Sep 2005 08:23:22 -
@@ -1,3 +1,8 @@
+2005-09-22  Jean-Marc Lasgouttes  <[EMAIL PROTECTED]>
+
+	* lyxinclude.m4 (LYX_PROG_CXX): do not enable stdlib-debug for
+	prereleases.
+
 2005-09-08  Angus Leeming  <[EMAIL PROTECTED]>
 
 	* spell.m4: correct grammar describing invocation of the
Index: config/lyxinclude.m4
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/config/lyxinclude.m4,v
retrieving revision 1.114
diff -u -p -r1.114 lyxinclude.m4
--- config/lyxinclude.m4	18 Jul 2005 14:24:27 -	1.114
+++ config/lyxinclude.m4	22 Sep 2005 08:23:22 -
@@ -186,7 +186,7 @@ AC_ARG_ENABLE(debug,
 
 AC_ARG_ENABLE(stdlib-debug,
   AC_HELP_STRING([--enable-stdlib-debug],[enable debug mode in the standard library]),,
-  [ if test $lyx_devel_version = yes -o $lyx_prerelease = yes ; then
+  [ if test $lyx_devel_version = yes ; then
   enable_stdlib_debug=yes;
 else
   enable_stdlib_debug=no;

[Patch] Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Martin Vermeer]

On Thu, 2005-09-22 at 03:26 +0300, Martin Vermeer wrote:


> I also noted that metrics is called twice for every keystroke. Surely one of
> those isn't necessary.
> 
> Sounds reasonable? Please test. Is it faster, or is it my imagination?

Here is a better patch, taking care of rowpainter too. metrics is still
called twice, but now (generally) only for the current paragraph, not
the whole screen. Ought to be faster. 

I saw no side effects.

- Martin

Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.595
diff -u -p -r1.595 BufferView_pimpl.C
--- BufferView_pimpl.C	15 Sep 2005 13:55:45 -	1.595
+++ BufferView_pimpl.C	22 Sep 2005 07:58:27 -
@@ -666,13 +666,16 @@ void BufferView::Pimpl::update(Update::f
 		theCoords.startUpdating();
 
 		// First drawing step
-		ViewMetricsInfo vi = metrics();
+		ViewMetricsInfo vi = metrics(flags & Update::SinglePar);
 		bool forceupdate(flags & Update::Force);
 
-		if ((flags & Update::FitCursor) && fitCursor()) {
-			forceupdate = true;
-			vi = metrics(flags & Update::SinglePar);
+		if (flags & Update::FitCursor) {
+			if (fitCursor()) {
+forceupdate = true;
+vi = metrics();
+			}
 		}
+
 		if (forceupdate) {
 			// Second drawing step
 			screen().redraw(*bv_, vi);
@@ -1340,7 +1343,9 @@ ViewMetricsInfo BufferView::Pimpl::metri
 
 	// Redo paragraphs above cursor if necessary
 	int y1 = y0;
-	while (!singlepar && y1 > 0 && pit1 > 0) {
+	while (y1 > 0 && pit1 > 0) {
+		if (singlepar && (pit1 < cursor_.pit()))
+			break;
 		y1 -= text->getPar(pit1).ascent();
 		--pit1;
 		text->redoParagraph(pit1);
@@ -1364,7 +1369,9 @@ ViewMetricsInfo BufferView::Pimpl::metri
 
 	// Redo paragraphs below cursor if necessary
 	int y2 = y0;
-	while (!singlepar && y2 < bv.workHeight() && pit2 < int(npit) - 1) {
+	while (y2 < bv.workHeight() && pit2 < int(npit) - 1) {
+		if (singlepar && (pit2 > cursor_.pit()))
+			break;
 		y2 += text->getPar(pit2).descent();
 		++pit2;
 		text->redoParagraph(pit2);
@@ -1386,6 +1393,7 @@ ViewMetricsInfo BufferView::Pimpl::metri
 << BOOST_CURRENT_FUNCTION
 << " y1: " << y1
 << " y2: " << y2
+<< " singlepar: " << singlepar
 << endl;
 
 	return ViewMetricsInfo(pit1, pit2, y1, y2, singlepar);
Index: lyxfunc.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v
retrieving revision 1.668
diff -u -p -r1.668 lyxfunc.C
--- lyxfunc.C	19 Sep 2005 09:55:49 -	1.668
+++ lyxfunc.C	22 Sep 2005 07:58:28 -
@@ -1555,9 +1555,9 @@ void LyXFunc::dispatch(FuncRequest const
 			// This also initializes the position cache for all insets
 			// in (at least partially) visible top-level paragraphs.
 			if (update)
-view()->update(Update::FitCursor | Update::Force);
+view()->update(Update::FitCursor | Update::Force | Update::SinglePar);
 			else
-view()->update(Update::FitCursor);
+view()->update(Update::FitCursor | Update::SinglePar);
 
 			// if we executed a mutating lfun, mark the buffer as dirty
 			// FIXME: Why not use flag.enabled() but call getStatus again?
Index: rowpainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v
retrieving revision 1.157
diff -u -p -r1.157 rowpainter.C
--- rowpainter.C	19 Sep 2005 11:18:20 -	1.157
+++ rowpainter.C	22 Sep 2005 07:58:28 -
@@ -787,12 +787,12 @@ void paintText(BufferView const & bv, Vi
 
 	// and grey out above (should not happen later)
 //	lyxerr << "par ascent: " << text->getPar(vi.p1).ascent() << endl;
-	if (vi.y1 > 0)
+	if (vi.y1 > 0 && !vi.singlepar)
 		pain.fillRectangle(0, 0, bv.workWidth(), vi.y1, LColor::bottomarea);
 
 	// and possibly grey out below
 //	lyxerr << "par descent: " << text->getPar(vi.p1).ascent() << endl;
-	if (vi.y2 < bv.workHeight())
+	if (vi.y2 < bv.workHeight() && !vi.singlepar)
 		pain.fillRectangle(0, vi.y2, bv.workWidth(), bv.workHeight() - vi.y2, LColor::bottomarea);
 }
 


signature.asc
Description: This is a digitally signed message part

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Jean-Marc Lasgouttes]

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> It looks like we're all seeing the same thing. Time to do some
Angus> profiling I guess. If someone gives me a prescription of what I
Angus> need to do to recompile lyx ready for profiling and how to use
Angus> gprof, I'll volunteer.

We have a --enable-profiling option nowadays. Note that it is not
enough in itself. You should add 
  --disable-assertions --disable-stdlib-debug -enable-optimization=-O2

The big problem with gprof is that I never manage to get it to count
the time spent in the Qt library. That makes its timings pretty
useless in the case we are interesting in. 

It is supposedly possible to use oprofile to get a nice system-wide
profile, and call-graph can be obtained with a really recent kernel
(2.6.12?). This would be the best solution, I guess.

JMarc

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Jean-Marc Lasgouttes]

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> Linux. (Debian unstable.) The machine running Tru64 unix is an
Angus> even older 333MHz single processor box and it's currently dead.
Angus> I've no real urge to resurrect it.

OK, I was about to suggest using 'pixie', in case it gives better
results than gprof.

JMarc

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Lars Gullik Bjønnes wrote:
| > | Angus> So I'd say that LyX cvs is still clearly slower than LyX
| > | Angus> 1.3, but it appears to be usable. Further, real world
| > | Angus> testing is needed though.
| 
| > | I guess we'll get plenty after release :)
| 
| > Angus, you turned up the optimization level ?
| 
| -g -O

When doing profiling runs you need -O2

| > | Lars, stdlib-debug is currently enabled for prereleases. Could we
| > | at least disable that? A prerelease should be compiled in the same
| > | conditions as a real release...
| 
| > Or almost... leave assertions in f.ex.
| 
| Incidentally, why don't we leave assertions in always? I'd imagine
| that guaranteed clean up and dumping of foo.lyx.emergency was of huge
| importance to our users.

They do quite a lot to the speed...

-- 
Lgb

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Georg Baum]

Angus Leeming wrote:

> It looks like we're all seeing the same thing. Time to do some profiling I
> guess. If someone gives me a prescription of what I need to do to
> recompile lyx ready for profiling and how to use gprof, I'll volunteer.

I would do this myself, but have no time right now. Here is the recipe:

Compile every file for that you want profile information with the -pg
switch. This switch is also needed for linking, so the quick solution would
be something like

LDFLAGS="-pg" CXXFLAGS="-pg" configure

Running LyX then generates a file gmon.out in the current directory. You can
generate human readable profiling information by running

gprof  >profile.txt

in that directory.


Georg

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Martin Vermeer]

On Wed, 21 Sep 2005 23:38:54 +0200 Alfredo Braunstein <[EMAIL PROTECTED]> wrote:

> Georg Baum wrote:
> 
> > I tried to reproduce this, and got similar results (including the
> speedup
> > if only one line is displayed), but only as long as I remained in one
> > paragraph. If I hit Enter from time to time everything was fine.
> > This looks as if the slowlyness is in the paragraph breaking
> algorithm.
> 
> Could the problem be that the painting algorithm has a precision of one
> paragraph --then if a big par is peeping at the top or bottom of the
> screen
> all of it is drawn (although possibly with NullPainter)?
> 
> Alfredo

That's part of the story. Another part is that a long long time ago, I tried
to implement a thing called Update::SinglePar. The idea was that, as long as
a paragraph's metrics don't change, you can type into it and _only it_ will be
updated.

That's the theory. Unfortunately, what is in CVS doesn't actually do this.
Still the whole screen gets updated, always, with rebreaking for every
paragraph. The singlepar code in metrics isn't actually used. My bad.

I tried the following modification, to make this stuff (1) work, and (2) 
work correctly as intended:


Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.595
diff -u -p -r1.595 BufferView_pimpl.C
--- BufferView_pimpl.C  15 Sep 2005 13:55:45 -  1.595
+++ BufferView_pimpl.C  21 Sep 2005 23:49:27 -
@@ -666,12 +666,12 @@ void BufferView::Pimpl::update(Update::f
theCoords.startUpdating();
 
// First drawing step
-   ViewMetricsInfo vi = metrics();
+   ViewMetricsInfo vi = metrics(flags & Update::SinglePar);
bool forceupdate(flags & Update::Force);
 
if ((flags & Update::FitCursor) && fitCursor()) {
forceupdate = true;
-   vi = metrics(flags & Update::SinglePar);
+   vi = metrics();
}
if (forceupdate) {
// Second drawing step
@@ -1340,7 +1340,9 @@ ViewMetricsInfo BufferView::Pimpl::metri
 
// Redo paragraphs above cursor if necessary
int y1 = y0;
-   while (!singlepar && y1 > 0 && pit1 > 0) {
+   while (y1 > 0 && pit1 > 0) {
+   if (singlepar && (pit1 < cursor_.pit()))
+   break;
y1 -= text->getPar(pit1).ascent();
--pit1;
text->redoParagraph(pit1);
@@ -1364,7 +1366,9 @@ ViewMetricsInfo BufferView::Pimpl::metri
 
// Redo paragraphs below cursor if necessary
int y2 = y0;
-   while (!singlepar && y2 < bv.workHeight() && pit2 < int(npit) - 1) {
+   while (y2 < bv.workHeight() && pit2 < int(npit) - 1) {
+   if (singlepar && (pit2 > cursor_.pit()))
+   break;
y2 += text->getPar(pit2).descent();
++pit2;
text->redoParagraph(pit2);
Index: text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v
retrieving revision 1.307
diff -u -p -r1.307 text3.C
--- text3.C 16 Sep 2005 10:06:09 -  1.307
+++ text3.C 21 Sep 2005 23:49:28 -
@@ -1130,6 +1130,8 @@ void LyXText::dispatch(LCursor & cur, Fu
if (!needsUpdate) {
// update only this paragraph
cur.bv().update(Update::SinglePar | Update::Force);
+   } else {
+   cur.bv().update(Update::Force);
}
 
bv->updateScrollbar();
Index: rowpainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v
retrieving revision 1.157
diff -u -p -r1.157 rowpainter.C
--- rowpainter.C19 Sep 2005 11:18:20 -  1.157
+++ rowpainter.C21 Sep 2005 23:49:28 -
@@ -792,8 +792,8 @@ void paintText(BufferView const & bv, Vi
 
// and possibly grey out below
 // lyxerr << "par descent: " << text->getPar(vi.p1).ascent() << endl;
-   if (vi.y2 < bv.workHeight())
-   pain.fillRectangle(0, vi.y2, bv.workWidth(), bv.workHeight() - 
vi.y2, LColor::bottomarea);
+// if (vi.y2 < bv.workHeight())
+// pain.fillRectangle(0, vi.y2, bv.workWidth(), bv.workHeight() - 
vi.y2, LColor::bottomarea);
 }
 
As you see, rowpainter/paintText throws a spanner in the works, and I had to
suppress the painting of the bottom grey area. Here just done by brute force 
for proof of principle. If this really helps to produce a speedup, this
should be done cleanly, presumably by providing paintText with a singlepar
argument and making the suppression conditional upon it.

I also noted that metrics is called twice for every keystroke. Surely one of
those isn't

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Angus Leeming]

Alfredo Braunstein wrote:

> Georg Baum wrote:
> 
>> I tried to reproduce this, and got similar results (including the
>> speedup if only one line is displayed), but only as long as I remained
>> in one paragraph. If I hit Enter from time to time everything was fine.
>> This looks as if the slowlyness is in the paragraph breaking algorithm.
> 
> Could the problem be that the painting algorithm has a precision of one
> paragraph --then if a big par is peeping at the top or bottom of the
> screen all of it is drawn (although possibly with NullPainter)?
> 
> Alfredo

Hi, Alfredo! Hope you and yours are all well.

It looks like we're all seeing the same thing. Time to do some profiling I
guess. If someone gives me a prescription of what I need to do to
recompile lyx ready for profiling and how to use gprof, I'll volunteer.

-- 
Angus

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Alfredo Braunstein]

Georg Baum wrote:

> I tried to reproduce this, and got similar results (including the speedup
> if only one line is displayed), but only as long as I remained in one
> paragraph. If I hit Enter from time to time everything was fine.
> This looks as if the slowlyness is in the paragraph breaking algorithm.

Could the problem be that the painting algorithm has a precision of one
paragraph --then if a big par is peeping at the top or bottom of the screen
all of it is drawn (although possibly with NullPainter)?

Alfredo

PS: Hrmmm... sorry Georg for the duplicate

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Georg Baum]

Bennett Helm wrote:

> I cannot -- even with gibberish -- type faster than LyX can handle
> when the document is otherwise empty, and LyX doesn't use many
> processor resources in this case.
> 
> After 5-10 lines of text are entered, it becomes noticeable that LyX
> is consuming more processor time than it had, though it's still fast
> enough that I don't detect a lag.
> 
> With more than 20 lines of text, it's possible for me to type fast
> enough that the CPU is pegged at 100% and I begin to notice a lag,
> though I would characterize it as usable.
> 
> With more than 25 lines, the lag is quite annoying: it takes a second
> or so to catch up after typing in a sentence.

I tried to reproduce this, and got similar results (including the speedup if
only one line is displayed), but only as long as I remained in one
paragraph. If I hit Enter from time to time everything was fine.
This looks as if the slowlyness is in the paragraph breaking algorithm.


Georg

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Angus Leeming]

Lars Gullik Bjønnes wrote:
> | Angus> So I'd say that LyX cvs is still clearly slower than LyX
> | Angus> 1.3, but it appears to be usable. Further, real world
> | Angus> testing is needed though.

> | I guess we'll get plenty after release :)

> Angus, you turned up the optimization level ?

-g -O

> | Lars, stdlib-debug is currently enabled for prereleases. Could we
> | at least disable that? A prerelease should be compiled in the same
> | conditions as a real release...

> Or almost... leave assertions in f.ex.

Incidentally, why don't we leave assertions in always? I'd imagine
that guaranteed clean up and dumping of foo.lyx.emergency was of huge
importance to our users.

-- 
Angus

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Angus Leeming]

Jean-Marc Lasgouttes wrote:
JMarc> On what kind of system is that?

Angus> A rather venerable 500MHz dual processor Dec Alpha.

JMarc> So that's a good testing machine. Does it run under 
JMarc> Tru64 unix or linux?

Linux. (Debian unstable.) The machine running Tru64 unix is an even
older 333MHz single processor box and it's currently dead. I've no
real urge to resurrect it.

-- 
Angus

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
| 
| Angus> Hi, Jean-Marc. I can confirm that LyX CVS is much, much quicker
| Angus> when compiled with --disable-stdlib-debug. I can still just
| Angus> about create a lag between what I type and what appears on the
| Angus> LyX screen when editting an existing paragraph, but only if I
| Angus> type garbage. If I type normally, all is fine.
| 
| On what kind of system is that?
| 
| Is it different with xforms?
| 
| Angus> So I'd say that LyX cvs is still clearly slower than LyX 1.3,
| Angus> but it appears to be usable. Further, real world testing is
| Angus> needed though.
| 
| I guess we'll get plenty after release :) 

Ansgus, you turned up the optimization level ?

| Lars, stdlib-debug is currently enabled for prereleases. Could we at
| least disable that? A prerelease should be compiled in the same
| conditions as a real release...

Or almost... leave assertions in f.ex.


-- 
Lgb

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Bennett Helm]

On Sep 21, 2005, at 11:56 AM, Jean-Marc Lasgouttes wrote:


"Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:



Bennett> I've just recompiled myself with --disable-stdlib-debug.
Bennett> Things in general (on Mac) seem to be faster *except* typing
Bennett> speed in long documents, which is not noticeably improved. I
Bennett> get the lag Angus describes even with typing normally (and
Bennett> I'm not a terrifically fast typist). I would say it's still
Bennett> unusable on Mac for anything but very short documents -- less
Bennett> than 2 pages.

If only we were able to get good profiles showing the problem...


I've tried! -- Perhaps I should use something other than Shark.app.  
Suggestions?



What are the exact conditions where this happens? Does typing at the
end of a paragraph make things better? Is it really related to the
size of the document, or to the amount of text on screen?


I cannot -- even with gibberish -- type faster than LyX can handle  
when the document is otherwise empty, and LyX doesn't use many  
processor resources in this case.


After 5-10 lines of text are entered, it becomes noticeable that LyX  
is consuming more processor time than it had, though it's still fast  
enough that I don't detect a lag.


With more than 20 lines of text, it's possible for me to type fast  
enough that the CPU is pegged at 100% and I begin to notice a lag,  
though I would characterize it as usable.


With more than 25 lines, the lag is quite annoying: it takes a second  
or so to catch up after typing in a sentence.


In every case, I'm simply typing ordinary text: no math insets, no  
footnotes, no graphics, no nothing. Adding these things doesn't seem  
to make a difference: the issue really has to do with normal text, as  
far as I can see.


The issue seems to be the amount of text on the screen rather than  
the size of the document: if I scroll down to the bottom of a large  
document so that only a single line is visible on screen, I can type  
at a normal speed. Moreover, the situation improves when I make the  
LyX window very small and type, even when the window is filled with  
text; conversely, larger windows seem to slow things down more.


When the screen is filled with text, there is only a slight  
improvement in speed in typing at the end of a paragraph rather than  
the middle. Typing in a new paragraph is the same as typing at the  
end of an old paragraph.


Bennett

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Jean-Marc Lasgouttes]

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> Jean-Marc Lasgouttes wrote: Hi, Jean-Marc. I can confirm that
Angus> LyX CVS is much, much quicker when compiled with
Angus> --disable-stdlib-debug. I can still just about create a lag
Angus> between what I type and what appears on the LyX screen when
Angus> editting an existing paragraph, but only if I type garbage. If
Angus> I type normally, all is fine.

>> On what kind of system is that?

Angus> A rather venerable 500MHz dual processor Dec Alpha.

So that's a good testing machine. Does it run under Tru64 unix or
linux?

JMarc

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Angus Leeming]

Jean-Marc Lasgouttes wrote:
> Angus> Hi, Jean-Marc. I can confirm that LyX CVS is much, much
> Angus> quicker when compiled with --disable-stdlib-debug. I can
> Angus> still just about create a lag between what I type and
> Angus> what appears on the LyX screen when editting an existing
> Angus> paragraph, but only if I type garbage. If I type normally,
> Angus> all is fine.

> On what kind of system is that?

A rather venerable 500MHz dual processor Dec Alpha.

> Is it different with xforms?

Nope. Exactly the same "feel". Normal typing in the middle of an
existing paragraph is OK. Typing garbage a;lskdfasldfj as quickly as
I can causes a lag.

-- 
Angus

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Jean-Marc Lasgouttes]

> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:

Bennett> I've just recompiled myself with --disable-stdlib-debug.
Bennett> Things in general (on Mac) seem to be faster *except* typing
Bennett> speed in long documents, which is not noticeably improved. I
Bennett> get the lag Angus describes even with typing normally (and
Bennett> I'm not a terrifically fast typist). I would say it's still
Bennett> unusable on Mac for anything but very short documents -- less
Bennett> than 2 pages.

If only we were able to get good profiles showing the problem...

What are the exact conditions where this happens? Does typing at the
end of a paragraph make things better? Is it really related to the
size of the document, or to the amount of text on screen?

JMarc

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Bennett Helm]

On Sep 21, 2005, at 11:27 AM, Angus Leeming wrote:


What is important is to check what happens with a normally optimized
build, especially with --disable-stdlib-debug.

Could you try that?


Hi, Jean-Marc. I can confirm that LyX CVS is much, much quicker when
compiled with --disable-stdlib-debug. I can still just about create a
lag between what I type and what appears on the LyX screen when
editting an existing paragraph, but only if I type garbage. If I type
normally, all is fine.

So I'd say that LyX cvs is still clearly slower than LyX 1.3, but it
appears to be usable. Further, real world testing is needed though.


I've just recompiled myself with --disable-stdlib-debug. Things in  
general (on Mac) seem to be faster *except* typing speed in long  
documents, which is not noticeably improved. I get the lag Angus  
describes even with typing normally (and I'm not a terrifically fast  
typist). I would say it's still unusable on Mac for anything but very  
short documents -- less than 2 pages.


Bennett

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Jean-Marc Lasgouttes]

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> Hi, Jean-Marc. I can confirm that LyX CVS is much, much quicker
Angus> when compiled with --disable-stdlib-debug. I can still just
Angus> about create a lag between what I type and what appears on the
Angus> LyX screen when editting an existing paragraph, but only if I
Angus> type garbage. If I type normally, all is fine.

On what kind of system is that?

Is it different with xforms?

Angus> So I'd say that LyX cvs is still clearly slower than LyX 1.3,
Angus> but it appears to be usable. Further, real world testing is
Angus> needed though.

I guess we'll get plenty after release :) 

Lars, stdlib-debug is currently enabled for prereleases. Could we at
least disable that? A prerelease should be compiled in the same
conditions as a real release...

JMarc

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Angus Leeming]

Jean-Marc Lasgouttes wrote:
> Angus> I don't want to sound like a miserable old sod, but... I just
> Angus> opened up a reasonably long document and started adding some
> Angus> new text in the middle of the first paragraph. I'm not a
> Angus> particularly fast typist but even I could outpace the screen
> Angus> drawing. Just normal text in a normal paragraph.

> Angus> I can't even use the excuse of running LyX remotely as I've
> Angus> done in the past. This was running locally. Everything is
> fine Angus> and dandy with LyX 1.3 and with all other apps that I
> use.

> What is important is to check what happens with a normally optimized
> build, especially with --disable-stdlib-debug. This is for example
> the cause of bug 1922:
> http://bugzilla.lyx.org/show_bug.cgi?id=1922#c11

> Could you try that?

> I really think stdlib-debug should not be on by default in cvs
> build, since it gives a false impression of the speed.

Hi, Jean-Marc. I can confirm that LyX CVS is much, much quicker when
compiled with --disable-stdlib-debug. I can still just about create a
lag between what I type and what appears on the LyX screen when
editting an existing paragraph, but only if I type garbage. If I type
normally, all is fine.

So I'd say that LyX cvs is still clearly slower than LyX 1.3, but it
appears to be usable. Further, real world testing is needed though.

-- 
Angus

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
| 
| Angus> I don't want to sound like a miserable old sod, but... I just
| Angus> opened up a reasonably long document and started adding some
| Angus> new text in the middle of the first paragraph. I'm not a
| Angus> particularly fast typist but even I could outpace the screen
| Angus> drawing. Just normal text in a normal paragraph.
| 
| Angus> I can't even use the excuse of running LyX remotely as I've
| Angus> done in the past. This was running locally. Everything is fine
| Angus> and dandy with LyX 1.3 and with all other apps that I use.
| 
| What is important is to check what happens with a normally optimized
| build, especially with --disable-stdlib-debug. This is for example the
| cause of bug 1922:
| http://bugzilla.lyx.org/show_bug.cgi?id=1922#c11
| 
| Could you try that?
| 
| I really think stdlib-debug should not be on by default in cvs build,
| since it gives a false impression of the speed.

I think it should be on for devel builds. It does catch mistakes.

-- 
Lgb

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Jean-Marc Lasgouttes]

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> Should I undefine _GLIBCXX_CONCEPT_CHECKS also? I guess that
Angus> would involve adding the --disable-concept-checks flags to my
Angus> configure command.

No, this one gives compile-time checks (error messages). It is
harmless at runtime.

JMarc

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Angus Leeming]

Jean-Marc Lasgouttes wrote:

>> "Angus" == Angus Leeming <[EMAIL PROTECTED]>
>> writes:
> 
> Angus> I don't want to sound like a miserable old sod, but... I just
> Angus> opened up a reasonably long document and started adding some
> Angus> new text in the middle of the first paragraph. I'm not a
> Angus> particularly fast typist but even I could outpace the screen
> Angus> drawing. Just normal text in a normal paragraph.
> 
> Angus> I can't even use the excuse of running LyX remotely as I've
> Angus> done in the past. This was running locally. Everything is
> fine Angus> and dandy with LyX 1.3 and with all other apps that I
> use.
> 
> What is important is to check what happens with a normally optimized
> build, especially with --disable-stdlib-debug. This is for example
> the cause of bug 1922:
> http://bugzilla.lyx.org/show_bug.cgi?id=1922#c11
> 
> Could you try that?
> 
> I really think stdlib-debug should not be on by default in cvs
> build, since it gives a false impression of the speed.

H. --disable-stdlib-debug results in the following change to my
config.h file:

 /* libstdc++ concept checking */
 /* #undef _GLIBCPP_CONCEPT_CHECKS */

 /* libstdc++ concept checking */
 #define _GLIBCXX_CONCEPT_CHECKS 1

 /* libstdc++ debug mode */
-#define _GLIBCXX_DEBUG 1
+/* #undef _GLIBCXX_DEBUG */

 /* libstdc++ pedantic debug mode */
-#define _GLIBCXX_DEBUG_PEDANTIC 1
+/* #undef _GLIBCXX_DEBUG_PEDANTIC */

Should I undefine _GLIBCXX_CONCEPT_CHECKS also? I guess that would
involve adding the --disable-concept-checks flags to my configure
command.

-- 
Angus

Re: LyX cvs (Qt frontend) is still sloooooooooooooooowwwwwwwwwwwwwww

[Jean-Marc Lasgouttes]

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> I don't want to sound like a miserable old sod, but... I just
Angus> opened up a reasonably long document and started adding some
Angus> new text in the middle of the first paragraph. I'm not a
Angus> particularly fast typist but even I could outpace the screen
Angus> drawing. Just normal text in a normal paragraph.

Angus> I can't even use the excuse of running LyX remotely as I've
Angus> done in the past. This was running locally. Everything is fine
Angus> and dandy with LyX 1.3 and with all other apps that I use.

What is important is to check what happens with a normally optimized
build, especially with --disable-stdlib-debug. This is for example the
cause of bug 1922:
http://bugzilla.lyx.org/show_bug.cgi?id=1922#c11

Could you try that?

I really think stdlib-debug should not be on by default in cvs build,
since it gives a false impression of the speed.

JMarc