Re: 1.4cvs performance problem over network when adding a paragraph
Angus Leeming a écrit : Abdelrazak Younes <[EMAIL PROTECTED]> writes: I would be very happy if you could review my code. One thing I like about your code is that it makes the code of clients of ParagraphList a lot more readable. One place where this isn't the case is in undo.C where code like this suggests that you haven't yet hit on the perfect interface. --- undo.C 24 Nov 2005 16:22:39 - 1.69 +++ undo.C 8 Feb 2006 21:39:52 - -106,7 +106,8 advance(first, first_pit); ParagraphList::const_iterator last = plist.begin(); advance(last, last_pit + 1); - undo.pars = ParagraphList(first, last); + /// \todo verify this + undo.pars = ParagraphList(plist, first_pit, last_pit+1); Ah... This is because I didn't go to the full monty... I forgot to erase those three lines: - advance(first, first_pit); - ParagraphList::const_iterator last = plist.begin(); - advance(last, last_pit + 1); It is better now, isn't it? [...] You've already shown me that you're a competent programmer with bundles of energy, so I'd like to welcome you aboard and state that, despite (maybe because of ;-)) the grumpiness, these guys have been a pleasure to spend time with. I'm sure that you'll have fun here and you'll learn as much as you contribute. The emphasis here is on writing quality code and there's a strong belief in peer review. So, stick with it ;-) I'll try but I am not sure I'll have the time to do that. Thanks for the nice words anyway :-) One thing I'm less keen on in your code is your use of multiple typedefs in the ParagraphList to mean the same thing If I knew I would have had that kind of comments I would have cleaned up the patch before sending it ;-) This was just proof of concept but this is not a reason, I know... Thanks, Abdel.
Re: 1.4cvs performance problem over network when adding a paragraph
Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > One thing I like about your code is that it makes the code of clients of > > ParagraphList a lot more readable. One place where this isn't the case is in > > undo.C where code like this suggests that you haven't yet hit on the perfect > > interface. > > > > --- undo.C 24 Nov 2005 16:22:39 - 1.69 > > +++ undo.C 8 Feb 2006 21:39:52 - > > -106,7 +106,8 > > advance(first, first_pit); > > ParagraphList::const_iterator last = plist.begin(); > > advance(last, last_pit + 1); > > - undo.pars = ParagraphList(first, last); > > + /// \todo verify this > > + undo.pars = ParagraphList(plist, first_pit, last_pit+1); > > Ah... This is because I didn't go to the full monty... I forgot to erase > those three lines: > - advance(first, first_pit); > - ParagraphList::const_iterator last = plist.begin(); > - advance(last, last_pit + 1); > > It is better now, isn't it? I think so, but if last_pit is a ParagraphList::iterator which won't necessarily model a Random Access Iterator in the future, you should probably use undo.pars = ParagraphList(plist, first_pit, boost::next(last_pit)); > > One thing I'm less keen on in your code is your use of multiple typedefs > > in the ParagraphList to mean the same thing > > If I knew I would have had that kind of comments I would have cleaned up > the patch before sending it > This was just proof of concept but this is not a reason, I know... But you asked me to review your code Keep up the good work. Angus
Re: 1.4cvs performance problem over network when adding a paragraph
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> >> +{
> >> + bool result=true;
> >> + for (size_t i=start; i >
> > bool result = true;
> > for (size_t i = start; i < end; ++i)
> >
> > People are picky here ;-}
>
> That picky?
Even pickier.
A good idiom to follow in for loops is to use
for (xxx; i != end; yyy)
rather than
for (xxx; i < end; yyy)
because you'll end up with consistent-looking code for all types of iterator,
even those that don't support operator<.
I'm pretty sure I read the suggestion in one of Scott Meyer's books.
Angus
Re: 1.4cvs performance problem over network when adding a paragraph
Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > I'll go into non-grumpy-mode after 1.4.0 is released (and when I have > this subversion thing up and going) > At least I will do my best to. That'd be a shame. I quite enjoyed grumpy. Angus
Re: 1.4cvs performance problem over network when adding a paragraph
Jean-Marc Lasgouttes wrote: This is what I was about to suggest: currently, every time a paragraph is created/killed, the whole document after it is duplicated. For images, this means a lot of work. In particular, I think a pixmap is created in the X server, which means a lot of data to transfer. Assuming this isn't going to hold up the release, I created bug 2287 with this information for future reference. Helge Hafting
Re: 1.4cvs performance problem over network when adding a paragraph
Helge == Helge Hafting [EMAIL PROTECTED] writes: Helge Assuming this isn't going to hold up the release, I created bug Helge 2287 with this information for future reference. Thanks.
Re: 1.4cvs performance problem over network when adding a paragraph
Jean-Marc Lasgouttes wrote: This is what I was about to suggest: currently, every time a paragraph is created/killed, the whole document after it is duplicated. For images, this means a lot of work. In particular, I think a pixmap is created in the X server, which means a lot of data to transfer. Assuming this isn't going to hold up the release, I created bug 2287 with this information for future reference. Helge Hafting
Re: 1.4cvs performance problem over network when adding a paragraph
> "Helge" == Helge Hafting <[EMAIL PROTECTED]> writes: Helge> Assuming this isn't going to hold up the release, I created bug Helge> 2287 with this information for future reference. Thanks.
Re: 1.4cvs performance problem over network when adding a paragraph
On Mon, Feb 06, 2006 at 09:59:42AM +0100, Jean-Marc Lasgouttes wrote: Helge == Helge Hafting [EMAIL PROTECTED] writes: Helge I tested the userguide, no problems there. Further testing Helge shows that it is related to images. I have some high resolution Helge images - of course I expect those to be slow. But the slowness Helge happen even in cases where images aren't on screen. Typical Helge case: This is what I was about to suggest: currently, every time a paragraph is created/killed, the whole document after it is duplicated. For images, this means a lot of work. In particular, I think a pixmap is created in the X server, which means a lot of data to transfer. We should try Abdel's 'transparent vector of pointers' approach soonish. Andre'
Re: 1.4cvs performance problem over network when adding a paragraph
On Mon, Feb 06, 2006 at 09:59:42AM +0100, Jean-Marc Lasgouttes wrote: > > "Helge" == Helge Hafting <[EMAIL PROTECTED]> writes: > > Helge> I tested the userguide, no problems there. Further testing > Helge> shows that it is related to images. I have some high resolution > Helge> images - of course I expect those to be slow. But the slowness > Helge> happen even in cases where images aren't on screen. Typical > Helge> case: > > This is what I was about to suggest: currently, every time a paragraph > is created/killed, the whole document after it is duplicated. For > images, this means a lot of work. In particular, I think a pixmap is > created in the X server, which means a lot of data to transfer. We should try Abdel's 'transparent vector of pointers' approach soonish. Andre'
Re: 1.4cvs performance problem over network when adding a paragraph
Martin Vermeer wrote: On Fri, Feb 03, 2006 at 04:02:41PM +0100, Helge Hafting wrote: There is a strange performance problem when displaying a lyx that is running on another machine. (ADSL connection) How fast is your ADSL? And is it the same both ways (A = Asymmetric)? It is a nice fast connection. It was something like 3000/768 although they keep increasing this in little chunks to stay ahead of competition. Most editing operations are fine (writing text, deleting, scrolling) there is no bandwith problem. But press enter so that a new paragraph is created. This operation takes 6 seconds in my case! The network gets busy for the 6 seconds, I have no idea what happens. It is not a case of too much work scrolling half of the display, for simply writing so much text that the existing paragraph breaks into several lines is not a problem at all. Also, grabbing the scrollbar and rolling through the document is fine. That is weird... if it was about whole-screen refresh, these operations should be slow too. I tested the userguide, no problems there. Further testing shows that it is related to images. I have some high resolution images - of course I expect those to be slow. But the slowness happen even in cases where images aren't on screen. Typical case: The document have some long bulleted lists, containing some figure floats with big images. They don't have to be on screen though - split a paragraph before or after the images, and it'll be slow as long as it is the same bullet list that contain images somewhere. Perhaps the explanation here is that the graphichs are close enough that lyx transfer them just in case? But strangely enough, splitting a paragraph is much worse than simply adding in-paragraph lines (ctrl+enter). I can push an image around with ctrl+enter, and it'll all be as snappy as having the file locally. The graphichs bounce around on the screen, clearly qt is smart enough to cache it on the xserver somehow. But split a paragraph (or add/remove one entirely) and slowness happens. Now, some remote graphichs related delays are expected, and not a reason to hold up 1.4.0. But I think paragraph manipulations must be doing something unnecessary, moving the graphics around is clearly not the problem here. There is lots of network traffic througout the delay period. The delays can be long, splitting a paragraph close to a bigger image gave me a 24 seconds break! It is just these operations that take everlasting 6 seconds: * Press enter to split a paragraph (or create a blank one) * Press backspace so as to delete a paragraph boundary, merging two paragraphs * Let the cursor leave an empty paragraph so lyx auto-destroys it. * Cutting/pasting an entire paragraph. Cutting/pasting the same amount if text inside a single bigger paragraph is not a proble, Clearly, something strange and unnecessary happens over the network when the number of paragraphs change. And it don't look like something that can be blamed on qt either. Just to make sure: same document locally is fast? And are there any differences between client and server installation (X?) that could explain this? Same document locally is fast, on the same xserver that cause delays when the document is remote. Using the display on the remote machine for local editing is also fast. Helge Hafting
Re: 1.4cvs performance problem over network when adding a paragraph
Helge == Helge Hafting [EMAIL PROTECTED] writes: Helge I tested the userguide, no problems there. Further testing Helge shows that it is related to images. I have some high resolution Helge images - of course I expect those to be slow. But the slowness Helge happen even in cases where images aren't on screen. Typical Helge case: This is what I was about to suggest: currently, every time a paragraph is created/killed, the whole document after it is duplicated. For images, this means a lot of work. In particular, I think a pixmap is created in the X server, which means a lot of data to transfer. JMarc
Re: 1.4cvs performance problem over network when adding a paragraph
On Mon, 2006-02-06 at 09:59 +0100, Jean-Marc Lasgouttes wrote: Helge == Helge Hafting [EMAIL PROTECTED] writes: Helge I tested the userguide, no problems there. Further testing Helge shows that it is related to images. I have some high resolution Helge images - of course I expect those to be slow. But the slowness Helge happen even in cases where images aren't on screen. Typical Helge case: This is what I was about to suggest: currently, every time a paragraph is created/killed, the whole document after it is duplicated. For images, this means a lot of work. In particular, I think a pixmap is created in the X server, which means a lot of data to transfer. JMarc Yes, this sounds like a plausible explanation. So we should go for Andre's homegrown insert/erase operation (or whatever it was). - Martin signature.asc Description: This is a digitally signed message part
Re: 1.4cvs performance problem over network when adding a paragraph
Martin Vermeer wrote: On Fri, Feb 03, 2006 at 04:02:41PM +0100, Helge Hafting wrote: There is a strange performance problem when displaying a lyx that is running on another machine. (ADSL connection) How fast is your ADSL? And is it the same both ways (A = Asymmetric)? It is a nice fast connection. It was something like 3000/768 although they keep increasing this in little chunks to stay ahead of competition. Most editing operations are fine (writing text, deleting, scrolling) there is no bandwith problem. But press enter so that a new paragraph is created. This operation takes 6 seconds in my case! The network gets busy for the 6 seconds, I have no idea what happens. It is not a case of too much work scrolling half of the display, for simply writing so much text that the existing paragraph breaks into several lines is not a problem at all. Also, grabbing the scrollbar and rolling through the document is fine. That is weird... if it was about whole-screen refresh, these operations should be slow too. I tested the userguide, no problems there. Further testing shows that it is related to images. I have some high resolution images - of course I expect those to be slow. But the slowness happen even in cases where images aren't on screen. Typical case: The document have some long bulleted lists, containing some figure floats with big images. They don't have to be on screen though - split a paragraph before or after the images, and it'll be slow as long as it is the same bullet list that contain images somewhere. Perhaps the explanation here is that the graphichs are "close enough" that lyx transfer them just in case? But strangely enough, splitting a paragraph is much worse than simply adding in-paragraph lines (ctrl+enter). I can push an image around with ctrl+enter, and it'll all be as snappy as having the file locally. The graphichs bounce around on the screen, clearly qt is smart enough to cache it on the xserver somehow. But split a paragraph (or add/remove one entirely) and slowness happens. Now, some remote graphichs related delays are expected, and not a reason to hold up 1.4.0. But I think paragraph manipulations must be doing something unnecessary, moving the graphics around is clearly not the problem here. There is lots of network traffic througout the delay period. The delays can be long, splitting a paragraph close to a bigger image gave me a 24 seconds break! It is just these operations that take everlasting 6 seconds: * Press enter to split a paragraph (or create a blank one) * Press backspace so as to delete a paragraph boundary, merging two paragraphs * Let the cursor leave an empty paragraph so lyx auto-destroys it. * Cutting/pasting an entire paragraph. Cutting/pasting the same amount if text inside a single bigger paragraph is not a proble, Clearly, something strange and unnecessary happens over the network when the number of paragraphs change. And it don't look like something that can be blamed on qt either. Just to make sure: same document locally is fast? And are there any differences between client and server installation (X?) that could explain this? Same document locally is fast, on the same xserver that cause delays when the document is remote. Using the display on the remote machine for local editing is also fast. Helge Hafting
Re: 1.4cvs performance problem over network when adding a paragraph
> "Helge" == Helge Hafting <[EMAIL PROTECTED]> writes: Helge> I tested the userguide, no problems there. Further testing Helge> shows that it is related to images. I have some high resolution Helge> images - of course I expect those to be slow. But the slowness Helge> happen even in cases where images aren't on screen. Typical Helge> case: This is what I was about to suggest: currently, every time a paragraph is created/killed, the whole document after it is duplicated. For images, this means a lot of work. In particular, I think a pixmap is created in the X server, which means a lot of data to transfer. JMarc
Re: 1.4cvs performance problem over network when adding a paragraph
On Mon, 2006-02-06 at 09:59 +0100, Jean-Marc Lasgouttes wrote: > > "Helge" == Helge Hafting <[EMAIL PROTECTED]> writes: > > Helge> I tested the userguide, no problems there. Further testing > Helge> shows that it is related to images. I have some high resolution > Helge> images - of course I expect those to be slow. But the slowness > Helge> happen even in cases where images aren't on screen. Typical > Helge> case: > > This is what I was about to suggest: currently, every time a paragraph > is created/killed, the whole document after it is duplicated. For > images, this means a lot of work. In particular, I think a pixmap is > created in the X server, which means a lot of data to transfer. > > JMarc Yes, this sounds like a plausible explanation. So we should go for Andre's homegrown insert/erase operation (or whatever it was). - Martin signature.asc Description: This is a digitally signed message part
Re: 1.4cvs performance problem over network when adding a paragraph
On Fri, Feb 03, 2006 at 04:02:41PM +0100, Helge Hafting wrote: There is a strange performance problem when displaying a lyx that is running on another machine. (ADSL connection) How fast is your ADSL? And is it the same both ways (A = Asymmetric)? I have a 256/256 kb ADSL (which thus != A) and don't remember seeing anything like this when logging in from job to home. But I didn't explicitly test, and cannot do so now. Most editing operations are fine (writing text, deleting, scrolling) there is no bandwith problem. But press enter so that a new paragraph is created. This operation takes 6 seconds in my case! The network gets busy for the 6 seconds, I have no idea what happens. It is not a case of too much work scrolling half of the display, for simply writing so much text that the existing paragraph breaks into several lines is not a problem at all. Also, grabbing the scrollbar and rolling through the document is fine. That is weird... if it was about whole-screen refresh, these operations should be slow too. It is just these operations that take everlasting 6 seconds: * Press enter to split a paragraph (or create a blank one) * Press backspace so as to delete a paragraph boundary, merging two paragraphs * Let the cursor leave an empty paragraph so lyx auto-destroys it. * Cutting/pasting an entire paragraph. Cutting/pasting the same amount if text inside a single bigger paragraph is not a proble, Clearly, something strange and unnecessary happens over the network when the number of paragraphs change. And it don't look like something that can be blamed on qt either. Just to make sure: same document locally is fast? And are there any differences between client and server installation (X?) that could explain this? The document is 15 pages, and view dvi is actually faster than enter when working over the net. Want a bugzilla report, or is this a known issue? Not to me it isn't. - Martin pgpMV5CGO37KL.pgp Description: PGP signature
Re: 1.4cvs performance problem over network when adding a paragraph
On Fri, Feb 03, 2006 at 04:02:41PM +0100, Helge Hafting wrote: > There is a strange performance problem when displaying a lyx that is > running on another machine. (ADSL connection) How fast is your ADSL? And is it the same both ways (A = Asymmetric)? I have a 256/256 kb ADSL (which thus != A) and don't remember seeing anything like this when logging in from job to home. But I didn't explicitly test, and cannot do so now. > Most editing operations are fine (writing text, deleting, scrolling) > there is no bandwith problem. But press enter so that a > new paragraph is created. This operation takes 6 seconds in my case! > > The network gets busy for the 6 seconds, I have no idea what happens. > > It is not a case of too much work scrolling half of the display, for simply > writing so much text that the existing paragraph breaks into > several lines is not a problem at all. Also, grabbing the > scrollbar and rolling through the document is fine. That is weird... if it was about whole-screen refresh, these operations should be slow too. > It is just these operations that take everlasting 6 seconds: > * Press enter to split a paragraph (or create a blank one) > * Press backspace so as to delete a paragraph > boundary, merging two paragraphs > * Let the cursor leave an empty paragraph so lyx auto-destroys it. > * Cutting/pasting an entire paragraph. Cutting/pasting the same amount > if text inside a single bigger paragraph is not a proble, > > Clearly, something strange and unnecessary happens over the network > when the number of paragraphs change. And it don't look like something > that can be blamed on qt either. Just to make sure: same document locally is fast? And are there any differences between client and server installation (X?) that could explain this? > The document is 15 pages, and "view dvi" is actually faster than "enter" > when working over the net. > > Want a bugzilla report, or is this a known issue? Not to me it isn't. - Martin pgpMV5CGO37KL.pgp Description: PGP signature
1.4cvs performance problem over network when adding a paragraph
There is a strange performance problem when displaying a lyx that is running on another machine. (ADSL connection) Most editing operations are fine (writing text, deleting, scrolling) there is no bandwith problem. But press enter so that a new paragraph is created. This operation takes 6 seconds in my case! The network gets busy for the 6 seconds, I have no idea what happens. It is not a case of too much work scrolling half of the display, for simply writing so much text that the existing paragraph breaks into several lines is not a problem at all. Also, grabbing the scrollbar and rolling through the document is fine. It is just these operations that take everlasting 6 seconds: * Press enter to split a paragraph (or create a blank one) * Press backspace so as to delete a paragraph boundary, merging two paragraphs * Let the cursor leave an empty paragraph so lyx auto-destroys it. * Cutting/pasting an entire paragraph. Cutting/pasting the same amount if text inside a single bigger paragraph is not a proble, Clearly, something strange and unnecessary happens over the network when the number of paragraphs change. And it don't look like something that can be blamed on qt either. The document is 15 pages, and view dvi is actually faster than enter when working over the net. Want a bugzilla report, or is this a known issue? Helge Hafting
1.4cvs performance problem over network when adding a paragraph
There is a strange performance problem when displaying a lyx that is running on another machine. (ADSL connection) Most editing operations are fine (writing text, deleting, scrolling) there is no bandwith problem. But press enter so that a new paragraph is created. This operation takes 6 seconds in my case! The network gets busy for the 6 seconds, I have no idea what happens. It is not a case of too much work scrolling half of the display, for simply writing so much text that the existing paragraph breaks into several lines is not a problem at all. Also, grabbing the scrollbar and rolling through the document is fine. It is just these operations that take everlasting 6 seconds: * Press enter to split a paragraph (or create a blank one) * Press backspace so as to delete a paragraph boundary, merging two paragraphs * Let the cursor leave an empty paragraph so lyx auto-destroys it. * Cutting/pasting an entire paragraph. Cutting/pasting the same amount if text inside a single bigger paragraph is not a proble, Clearly, something strange and unnecessary happens over the network when the number of paragraphs change. And it don't look like something that can be blamed on qt either. The document is 15 pages, and "view dvi" is actually faster than "enter" when working over the net. Want a bugzilla report, or is this a known issue? Helge Hafting
