Re: Beta1 is slow on undo

2017-11-02 Thread Scott Kostyshak
On Thu, Nov 02, 2017 at 03:47:21PM +, racoon wrote:
> On 07.10.2017 19:09, racoon wrote:
> > Hi,
> > 
> > I noticed that beta1 shows some slowness when undoing with some of my
> > documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
> > second to respond to it.
> > 
> > Did anyone notice this? I don't have a very fast computer though.
> 
> In RC1 the undo speed is back to normal, i.e. barely noticeable delay.
> Thanks!

Thanks for your great testing Daniel. I particularly appreciate that you
follow up on issues and let us know that certain ones are fixed.

Thanks for your attention to detail,

Scott


signature.asc
Description: PGP signature


Re: Beta1 is slow on undo

2017-11-02 Thread racoon

On 07.10.2017 19:09, racoon wrote:

Hi,

I noticed that beta1 shows some slowness when undoing with some of my 
documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a 
second to respond to it.


Did anyone notice this? I don't have a very fast computer though.


In RC1 the undo speed is back to normal, i.e. barely noticeable delay. 
Thanks!


Daniel



Best,

Daniel







Re: Beta1 is slow on undo

2017-10-18 Thread Jürgen Spitzmüller
2017-10-17 21:48 GMT+02:00 Richard Heck :

> Sounds definitely worth it then. If an explicit +1 is needed, consider
> that it.
>

Done for master. Will backport to 2.3.x. later today.

Jürgen


>
> Richard
>
>
>


Re: Beta1 is slow on undo

2017-10-17 Thread Scott Kostyshak
On Tue, Oct 17, 2017 at 09:19:06PM +, Uwe Stöhr wrote:
> El 15.10.2017 a las 18:58, Scott Kostyshak escribió:
> 
> > Uwe, can you check the file that racoon attached at [1] to see if you
> > can reproduce...
> > 
> > Right after (3) do you see a small delay, compared with when you do the
> > above on 2.2.3?
> 
> Dear Scott,
> 
> I get a small delay but it is as long as in LyX 2.2.4dev.

Thanks for checking, Uwe.

Scott


signature.asc
Description: PGP signature


Re: Beta1 is slow on undo

2017-10-17 Thread Uwe Stöhr

El 15.10.2017 a las 18:58, Scott Kostyshak escribió:


Uwe, can you check the file that racoon attached at [1] to see if you
can reproduce...

Right after (3) do you see a small delay, compared with when you do the
above on 2.2.3?


Dear Scott,

I get a small delay but it is as long as in LyX 2.2.4dev. The delay is 
shorter than 1 second.


regards Uwe


Re: Beta1 is slow on undo

2017-10-17 Thread Richard Heck
On 10/17/2017 01:22 AM, Jürgen Spitzmüller wrote:
> Am Montag, den 16.10.2017, 14:58 -0400 schrieb Richard Heck:
>> Without profiling, it would be hard to know for sure, but I'd guess
>> it was worth it. Certainly re-reading huge files over a high-latency 
>> connection could slow things down.
> By subjective measure, it is noticeable with several insets that
> include the same (big) BibTeX file.

Sounds definitely worth it then. If an explicit +1 is needed, consider
that it.

Richard




signature.asc
Description: OpenPGP digital signature


Re: Beta1 is slow on undo

2017-10-16 Thread Jürgen Spitzmüller
Am Montag, den 16.10.2017, 14:58 -0400 schrieb Richard Heck:
> Without profiling, it would be hard to know for sure, but I'd guess
> it
> was worth it. Certainly
> re-reading huge files over a high-latency connection could slow
> things down.

By subjective measure, it is noticeable with several insets that
include the same (big) BibTeX file.

Jürgen

> 
> Richard
> 
> 

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


Re: Beta1 is slow on undo

2017-10-16 Thread Richard Heck
On 10/16/2017 02:04 AM, Jürgen Spitzmüller wrote:
> Am Sonntag, den 15.10.2017, 18:41 -0400 schrieb Richard Heck:
>> No, it comes whenever a document contains a BibTeX inset. A better
>> patch
>> would make it happen
>> only when a BibTeX inset was involved. Then the delay is no surprise:
>> Of
>> course we have to reread
>> the files.
> The attached patch does not address this very bug, but I have noted
> that we unnecessarily read bibtex files multiple time (e.g. with
> multiple bibtex insets in master/child constellations or with
> subdivided bibliographies/chapterbib).
>
> The attached patch assures each file is only parsed once within a
> single collectBibkey() process. It will slightly speed up the process
> in some circumstances.
>
> Is it worth it?

Without profiling, it would be hard to know for sure, but I'd guess it
was worth it. Certainly
re-reading huge files over a high-latency connection could slow things down.

Richard




Re: Beta1 is slow on undo

2017-10-16 Thread Jürgen Spitzmüller
Am Sonntag, den 15.10.2017, 18:41 -0400 schrieb Richard Heck:
> No, it comes whenever a document contains a BibTeX inset. A better
> patch
> would make it happen
> only when a BibTeX inset was involved. Then the delay is no surprise:
> Of
> course we have to reread
> the files.

The attached patch does not address this very bug, but I have noted
that we unnecessarily read bibtex files multiple time (e.g. with
multiple bibtex insets in master/child constellations or with
subdivided bibliographies/chapterbib).

The attached patch assures each file is only parsed once within a
single collectBibkey() process. It will slightly speed up the process
in some circumstances.

Is it worth it?

Jürgen

> 
> Richard
> diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 9c42b07e7f..8182893a1a 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -2446,15 +2446,16 @@ void Buffer::reloadBibInfoCache() const
 		return;
 
 	d->bibinfo_.clear();
-	collectBibKeys();
+	FileNameList checkedFiles;
+	collectBibKeys(checkedFiles);
 	d->bibinfo_cache_valid_ = true;
 }
 
 
-void Buffer::collectBibKeys() const
+void Buffer::collectBibKeys(FileNameList & checkedFiles) const
 {
 	for (InsetIterator it = inset_iterator_begin(inset()); it; ++it)
-		it->collectBibKeys(it);
+		it->collectBibKeys(it, checkedFiles);
 }
 
 
diff --git a/src/Buffer.h b/src/Buffer.h
index 165f5d8795..35e7632973 100644
--- a/src/Buffer.h
+++ b/src/Buffer.h
@@ -17,6 +17,7 @@
 #include "support/unique_ptr.h"
 #include "support/strfwd.h"
 #include "support/types.h"
+#include "support/FileNameList.h"
 
 #include 
 #include 
@@ -520,7 +521,7 @@ public:
 	/// or just for it, if it isn't a child.
 	BiblioInfo const & masterBibInfo() const;
 	/// collect bibliography info from the various insets in this buffer.
-	void collectBibKeys() const;
+	void collectBibKeys(support::FileNameList &) const;
 	/// add some BiblioInfo to our cache
 	void addBiblioInfo(BiblioInfo const & bi) const;
 	/// add a single piece of bibliography info to our cache
diff --git a/src/insets/Inset.h b/src/insets/Inset.h
index f10ab3f883..ce17c8193a 100644
--- a/src/insets/Inset.h
+++ b/src/insets/Inset.h
@@ -23,6 +23,7 @@
 
 #include "support/strfwd.h"
 #include "support/types.h"
+#include "support/FileNameList.h"
 
 #include 
 
@@ -529,7 +530,7 @@ public:
 	  UpdateType /* utype*/,
 	  TocBackend & /* tocbackend */) const {}
 	/// Collect BibTeX information
-	virtual void collectBibKeys(InsetIterator const &) const {}
+	virtual void collectBibKeys(InsetIterator const &, support::FileNameList &) const {}
 	/// Update the counters of this inset and of its contents.
 	/// The boolean indicates whether we are preparing for output, e.g.,
 	/// of XHTML.
diff --git a/src/insets/InsetBibitem.cpp b/src/insets/InsetBibitem.cpp
index afc30ae37d..d5ebaf7640 100644
--- a/src/insets/InsetBibitem.cpp
+++ b/src/insets/InsetBibitem.cpp
@@ -285,7 +285,7 @@ docstring bibitemWidest(Buffer const & buffer, OutputParams const & runparams)
 }
 
 
-void InsetBibitem::collectBibKeys(InsetIterator const & it) const
+void InsetBibitem::collectBibKeys(InsetIterator const & it, FileNameList & /*checkedFiles*/) const
 {
 	docstring const key = getParam("key");
 	docstring const label = getParam("label");
diff --git a/src/insets/InsetBibitem.h b/src/insets/InsetBibitem.h
index 41497e1849..ba33732ad0 100644
--- a/src/insets/InsetBibitem.h
+++ b/src/insets/InsetBibitem.h
@@ -60,7 +60,7 @@ public:
 	///
 	docstring xhtml(XHTMLStream &, OutputParams const &) const;
 	///
-	void collectBibKeys(InsetIterator const &) const;
+	void collectBibKeys(InsetIterator const &, support::FileNameList &) const;
 	/// update the counter of this inset
 	void updateBuffer(ParIterator const &, UpdateType);
 	///@}
diff --git a/src/insets/InsetBibtex.cpp b/src/insets/InsetBibtex.cpp
index a905110773..30b169acb0 100644
--- a/src/insets/InsetBibtex.cpp
+++ b/src/insets/InsetBibtex.cpp
@@ -645,13 +645,13 @@ namespace {
 } // namespace
 
 
-void InsetBibtex::collectBibKeys(InsetIterator const & /*di*/) const
+void InsetBibtex::collectBibKeys(InsetIterator const & /*di*/, FileNameList & checkedFiles) const
 {
-	parseBibTeXFiles();
+	parseBibTeXFiles(checkedFiles);
 }
 
 
-void InsetBibtex::parseBibTeXFiles() const
+void InsetBibtex::parseBibTeXFiles(FileNameList & checkedFiles) const
 {
 	// This bibtex parser is a first step to parse bibtex files
 	// more precisely.
@@ -678,7 +678,14 @@ void InsetBibtex::parseBibTeXFiles() const
 	support::FileNamePairList::const_iterator it = files.begin();
 	support::FileNamePairList::const_iterator en = files.end();
 	for (; it != en; ++ it) {
-		ifdocstream ifs(it->second.toFilesystemEncoding().c_str(),
+		FileName const bibfile = it->second;
+		if (find(checkedFiles.begin(), checkedFiles.end(), bibfile) != checkedFiles.end())
+			// already checked this one. Skip.
+			continue;
+		else
+			// record that we check this.
+			checkedFiles.push_back(bibfile);
+		ifdocstream 

Re: Beta1 is slow on undo

2017-10-15 Thread Richard Heck
On 10/15/2017 06:52 PM, Scott Kostyshak wrote:
> On Sun, Oct 15, 2017 at 10:41:52PM +, Richard Heck wrote:
>> On 10/15/2017 03:02 PM, Scott Kostyshak wrote:
>>> On Sun, Oct 15, 2017 at 05:27:26PM +, Richard Heck wrote:
>>>
 I propose to revert that commit in all branches pending a better
 solution. I don't think that will be
 too difficult to find. It's just a matter of doing the work.
>>> Reverting in 2.2.x makes sense to me to be extra safe. As for 2.3.x, I
>>> don't have a strong preference. It's up to you to decide the tradeoff
>>> between the cost of a small delay and the cost of #9185 (both costs seem
>>> small to me). From what I understand, the delay in undo only comes when
>>> a BibTeX inset is involved, which I imagine is not very often.
>> No, it comes whenever a document contains a BibTeX inset. A better patch
>> would make it happen
>> only when a BibTeX inset was involved. Then the delay is no surprise: Of
>> course we have to reread
>> the files.
> Ah I see. I agree then that reverting in the other branches as well is a
> good idea.

I have reverted all of them and added some comments to the bug, which is
actually #9158
    https://www.lyx.org/trac/ticket/9158

Richard



Re: Beta1 is slow on undo

2017-10-15 Thread Scott Kostyshak
On Sun, Oct 15, 2017 at 10:41:52PM +, Richard Heck wrote:
> On 10/15/2017 03:02 PM, Scott Kostyshak wrote:
> > On Sun, Oct 15, 2017 at 05:27:26PM +, Richard Heck wrote:
> >
> >> I propose to revert that commit in all branches pending a better
> >> solution. I don't think that will be
> >> too difficult to find. It's just a matter of doing the work.
> > Reverting in 2.2.x makes sense to me to be extra safe. As for 2.3.x, I
> > don't have a strong preference. It's up to you to decide the tradeoff
> > between the cost of a small delay and the cost of #9185 (both costs seem
> > small to me). From what I understand, the delay in undo only comes when
> > a BibTeX inset is involved, which I imagine is not very often.
> 
> No, it comes whenever a document contains a BibTeX inset. A better patch
> would make it happen
> only when a BibTeX inset was involved. Then the delay is no surprise: Of
> course we have to reread
> the files.

Ah I see. I agree then that reverting in the other branches as well is a
good idea.

Scott


signature.asc
Description: PGP signature


Re: Beta1 is slow on undo

2017-10-15 Thread Richard Heck
On 10/15/2017 03:02 PM, Scott Kostyshak wrote:
> On Sun, Oct 15, 2017 at 05:27:26PM +, Richard Heck wrote:
>
>> I propose to revert that commit in all branches pending a better
>> solution. I don't think that will be
>> too difficult to find. It's just a matter of doing the work.
> Reverting in 2.2.x makes sense to me to be extra safe. As for 2.3.x, I
> don't have a strong preference. It's up to you to decide the tradeoff
> between the cost of a small delay and the cost of #9185 (both costs seem
> small to me). From what I understand, the delay in undo only comes when
> a BibTeX inset is involved, which I imagine is not very often.

No, it comes whenever a document contains a BibTeX inset. A better patch
would make it happen
only when a BibTeX inset was involved. Then the delay is no surprise: Of
course we have to reread
the files.

Richard



Re: Beta1 is slow on undo

2017-10-15 Thread Scott Kostyshak
On Sun, Oct 15, 2017 at 05:27:26PM +, Richard Heck wrote:

> I propose to revert that commit in all branches pending a better
> solution. I don't think that will be
> too difficult to find. It's just a matter of doing the work.

Reverting in 2.2.x makes sense to me to be extra safe. As for 2.3.x, I
don't have a strong preference. It's up to you to decide the tradeoff
between the cost of a small delay and the cost of #9185 (both costs seem
small to me). From what I understand, the delay in undo only comes when
a BibTeX inset is involved, which I imagine is not very often.

Thanks,

Scott


signature.asc
Description: PGP signature


Re: Beta1 is slow on undo

2017-10-15 Thread Richard Heck
On 10/15/2017 12:58 PM, Scott Kostyshak wrote:
> On Sun, Oct 08, 2017 at 02:19:19PM +, racoon wrote:
>> On 08.10.2017 00:19, Scott Kostyshak wrote:
>>> On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:
 On 10/07/2017 12:09 PM, racoon wrote:
> Hi,
>
> I noticed that beta1 shows some slowness when undoing with some of my
> documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
> second to respond to it.
>
> Did anyone notice this? I don't have a very fast computer though.
 Yes, I have also seen that, and my machines are pretty fast.
>>> I can't reproduce. My test case was to open the user guide, selected
>>> all, delete, and undo. Both were instantaneous for me. Do you have a
>>> better test case for me?
>> Okay, I think I have narrowed it down to the inclusion of any bibliography.
>> Test case attached.
> Uwe, can you check the file that racoon attached at [1] to see if you
> can reproduce. I can reproduce but only with a very small delay, not the
> one second delay racoon found. So perhaps it is platform-dependent. To
> reproduce:
>
> 1. Open the file at [1].
> 2. Delete the BibTeX inset.
> 3. Undo.
>
> Right after (3) do you see a small delay, compared with when you do the
> above on 2.2.3?

I am confident that Scott's identification of 02847641 as the culprit is
correct.  That forces a re-read
of all BibTeX files on every undo or redo. How long that takes will
depend upon how big the files
are, how fast the disk access is, etc.

I propose to revert that commit in all branches pending a better
solution. I don't think that will be
too difficult to find. It's just a matter of doing the work.

Richard



Re: Beta1 is slow on undo

2017-10-15 Thread Scott Kostyshak
On Sun, Oct 08, 2017 at 02:19:19PM +, racoon wrote:
> On 08.10.2017 00:19, Scott Kostyshak wrote:
> > On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:
> > > On 10/07/2017 12:09 PM, racoon wrote:
> > > > Hi,
> > > > 
> > > > I noticed that beta1 shows some slowness when undoing with some of my
> > > > documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
> > > > second to respond to it.
> > > > 
> > > > Did anyone notice this? I don't have a very fast computer though.
> > > 
> > > Yes, I have also seen that, and my machines are pretty fast.
> > 
> > I can't reproduce. My test case was to open the user guide, selected
> > all, delete, and undo. Both were instantaneous for me. Do you have a
> > better test case for me?
> 
> Okay, I think I have narrowed it down to the inclusion of any bibliography.
> Test case attached.

Uwe, can you check the file that racoon attached at [1] to see if you
can reproduce. I can reproduce but only with a very small delay, not the
one second delay racoon found. So perhaps it is platform-dependent. To
reproduce:

1. Open the file at [1].
2. Delete the BibTeX inset.
3. Undo.

Right after (3) do you see a small delay, compared with when you do the
above on 2.2.3?

Scott


[1]
https://www.mail-archive.com/search?l=mid=ordc32%24s9j%241%40blaine.gmane.org


signature.asc
Description: PGP signature


Re: Beta1 is slow on undo

2017-10-15 Thread Scott Kostyshak
On Wed, Oct 11, 2017 at 03:35:34PM +, Richard Heck wrote:
> On 10/08/2017 10:19 AM, racoon wrote:
> > On 08.10.2017 00:19, Scott Kostyshak wrote:
> >> On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:
> >>> On 10/07/2017 12:09 PM, racoon wrote:
>  Hi,
> 
>  I noticed that beta1 shows some slowness when undoing with some of my
>  documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
>  second to respond to it.
> 
>  Did anyone notice this? I don't have a very fast computer though.
> >>>
> >>> Yes, I have also seen that, and my machines are pretty fast.
> >>
> >> I can't reproduce. My test case was to open the user guide, selected
> >> all, delete, and undo. Both were instantaneous for me. Do you have a
> >> better test case for me?
> >
> > Okay, I think I have narrowed it down to the inclusion of any
> > bibliography. Test case attached.
> 
> In investigating this, I typed a bunch of short lines: a, b, c, d, etc,
> all alone on their own lines. I did not see slowness on undo until I had
> typed quite a few, and then suddenly there it was. But then it was gone
> again. I'll try again later to figure out how to reproduce it reliably.
> 
> What is clear is that undo is a lot slower when entire lines are being
> removed or replaced, as opposed merely to part of a single line,
> especially the last character being restored. I would guess this is
> because we do a full screen redraw in the slower case.

Richard, is the above slowness a change with respect to 2.2.x?

Scott


signature.asc
Description: PGP signature


Re: Beta1 is slow on undo

2017-10-11 Thread Jean-Marc Lasgouttes

Le 11/10/2017 à 17:35, Richard Heck a écrit :

What is clear is that undo is a lot slower when entire lines are being
removed or replaced, as opposed merely to part of a single line,
especially the last character being restored. I would guess this is
because we do a full screen redraw in the slower case.


A full screen redraw should not create a delay that is almost a second, 
like what is described in the report. I have not had time to do some 
profiling yet. Doing so is still a pain on Linux (I wish I could get 
sysprof to work).


JMarc


Re: Beta1 is slow on undo

2017-10-11 Thread Richard Heck
On 10/08/2017 10:19 AM, racoon wrote:
> On 08.10.2017 00:19, Scott Kostyshak wrote:
>> On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:
>>> On 10/07/2017 12:09 PM, racoon wrote:
 Hi,

 I noticed that beta1 shows some slowness when undoing with some of my
 documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
 second to respond to it.

 Did anyone notice this? I don't have a very fast computer though.
>>>
>>> Yes, I have also seen that, and my machines are pretty fast.
>>
>> I can't reproduce. My test case was to open the user guide, selected
>> all, delete, and undo. Both were instantaneous for me. Do you have a
>> better test case for me?
>
> Okay, I think I have narrowed it down to the inclusion of any
> bibliography. Test case attached.

In investigating this, I typed a bunch of short lines: a, b, c, d, etc,
all alone on their own lines. I did not see slowness on undo until I had
typed quite a few, and then suddenly there it was. But then it was gone
again. I'll try again later to figure out how to reproduce it reliably.

What is clear is that undo is a lot slower when entire lines are being
removed or replaced, as opposed merely to part of a single line,
especially the last character being restored. I would guess this is
because we do a full screen redraw in the slower case.

Richard



Re: Beta1 is slow on undo

2017-10-09 Thread Jean-Marc Lasgouttes
Le 9 octobre 2017 20:25:41 GMT+02:00, racoon  a écrit :
>I think Richard mentioned as well that he does not get that much delay 
>either. It might be due to my archaic system (Windows 7 Core 2 Duo @
>1.8 
>GHz). I know I should try to get a new one.. But so far I have been
>able 
>to use LyX with full satisfaction. And there may be others on slow
>machines.
>
>Daniel

This is not supposed to be slow. Let's see what we can do.

JMarc


Re: Beta1 is slow on undo

2017-10-09 Thread racoon

On 09.10.2017 07:28, Scott Kostyshak wrote:

On Sun, Oct 08, 2017 at 03:01:49PM +, Richard Heck wrote:

On 10/08/2017 10:19 AM, racoon wrote:

On 08.10.2017 00:19, Scott Kostyshak wrote:

On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:

On 10/07/2017 12:09 PM, racoon wrote:

Hi,

I noticed that beta1 shows some slowness when undoing with some of my
documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
second to respond to it.

Did anyone notice this? I don't have a very fast computer though.


Yes, I have also seen that, and my machines are pretty fast.


I can't reproduce. My test case was to open the user guide, selected
all, delete, and undo. Both were instantaneous for me. Do you have a
better test case for me?


Okay, I think I have narrowed it down to the inclusion of any
bibliography. Test case attached.


That would make sense, at least in so far as bibliography handling was
changed a lot. But it's hard to imagine why it would affect undo. Do we
re-read the bibliography or something now after an undo?


Bisect points to 02847641. I want to emphasize though that I only see a
very minor increase in slowness. I would not have realized it if it
weren't pointed out. It is certainly not a second delay for me. So
perhaps this is not the change that Richard and racoon are seeing.


I think Richard mentioned as well that he does not get that much delay 
either. It might be due to my archaic system (Windows 7 Core 2 Duo @ 1.8 
GHz). I know I should try to get a new one.. But so far I have been able 
to use LyX with full satisfaction. And there may be others on slow machines.


Daniel



Re: Beta1 is slow on undo

2017-10-08 Thread Scott Kostyshak
On Sun, Oct 08, 2017 at 03:01:49PM +, Richard Heck wrote:
> On 10/08/2017 10:19 AM, racoon wrote:
> > On 08.10.2017 00:19, Scott Kostyshak wrote:
> >> On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:
> >>> On 10/07/2017 12:09 PM, racoon wrote:
>  Hi,
> 
>  I noticed that beta1 shows some slowness when undoing with some of my
>  documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
>  second to respond to it.
> 
>  Did anyone notice this? I don't have a very fast computer though.
> >>>
> >>> Yes, I have also seen that, and my machines are pretty fast.
> >>
> >> I can't reproduce. My test case was to open the user guide, selected
> >> all, delete, and undo. Both were instantaneous for me. Do you have a
> >> better test case for me?
> >
> > Okay, I think I have narrowed it down to the inclusion of any
> > bibliography. Test case attached.
> 
> That would make sense, at least in so far as bibliography handling was
> changed a lot. But it's hard to imagine why it would affect undo. Do we
> re-read the bibliography or something now after an undo?

Bisect points to 02847641. I want to emphasize though that I only see a
very minor increase in slowness. I would not have realized it if it
weren't pointed out. It is certainly not a second delay for me. So
perhaps this is not the change that Richard and racoon are seeing.

Scott


signature.asc
Description: PGP signature


Re: Beta1 is slow on undo

2017-10-08 Thread Scott Kostyshak
On Sun, Oct 08, 2017 at 02:19:19PM +, racoon wrote:
> On 08.10.2017 00:19, Scott Kostyshak wrote:
> > On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:
> > > On 10/07/2017 12:09 PM, racoon wrote:
> > > > Hi,
> > > > 
> > > > I noticed that beta1 shows some slowness when undoing with some of my
> > > > documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
> > > > second to respond to it.
> > > > 
> > > > Did anyone notice this? I don't have a very fast computer though.
> > > 
> > > Yes, I have also seen that, and my machines are pretty fast.
> > 
> > I can't reproduce. My test case was to open the user guide, selected
> > all, delete, and undo. Both were instantaneous for me. Do you have a
> > better test case for me?
> 
> Okay, I think I have narrowed it down to the inclusion of any bibliography.
> Test case attached.

For me it is very slightly slower. Definitely not 1 second, maybe .2
seconds slower? I have no idea if this is due to differences e.g. in
compiler. I will check and try to do a bisect.

Thanks,

Scott


signature.asc
Description: PGP signature


Re: Beta1 is slow on undo

2017-10-08 Thread racoon

On 08.10.2017 16:19, racoon wrote:

On 08.10.2017 00:19, Scott Kostyshak wrote:

On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:

On 10/07/2017 12:09 PM, racoon wrote:

Hi,

I noticed that beta1 shows some slowness when undoing with some of my
documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
second to respond to it.

Did anyone notice this? I don't have a very fast computer though.


Yes, I have also seen that, and my machines are pretty fast.


I can't reproduce. My test case was to open the user guide, selected
all, delete, and undo. Both were instantaneous for me. Do you have a
better test case for me?


Okay, I think I have narrowed it down to the inclusion of any 
bibliography. Test case attached.


I just wanted to add that, at least on my slow machine, this delay is a 
bit annoying since sometimes I am not sure whether the undo was done and 
execute it again leaving me with uncertainty what exactly was undone. So 
I have to go back and forth in the undo sequence to figure out where I 
am in it.




Re: Beta1 is slow on undo

2017-10-08 Thread Richard Heck
On 10/08/2017 10:19 AM, racoon wrote:
> On 08.10.2017 00:19, Scott Kostyshak wrote:
>> On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:
>>> On 10/07/2017 12:09 PM, racoon wrote:
 Hi,

 I noticed that beta1 shows some slowness when undoing with some of my
 documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
 second to respond to it.

 Did anyone notice this? I don't have a very fast computer though.
>>>
>>> Yes, I have also seen that, and my machines are pretty fast.
>>
>> I can't reproduce. My test case was to open the user guide, selected
>> all, delete, and undo. Both were instantaneous for me. Do you have a
>> better test case for me?
>
> Okay, I think I have narrowed it down to the inclusion of any
> bibliography. Test case attached.

That would make sense, at least in so far as bibliography handling was
changed a lot. But it's hard to imagine why it would affect undo. Do we
re-read the bibliography or something now after an undo?

Richard



Re: Beta1 is slow on undo

2017-10-08 Thread racoon

On 08.10.2017 00:19, Scott Kostyshak wrote:

On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:

On 10/07/2017 12:09 PM, racoon wrote:

Hi,

I noticed that beta1 shows some slowness when undoing with some of my
documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
second to respond to it.

Did anyone notice this? I don't have a very fast computer though.


Yes, I have also seen that, and my machines are pretty fast.


I can't reproduce. My test case was to open the user guide, selected
all, delete, and undo. Both were instantaneous for me. Do you have a
better test case for me?


Okay, I think I have narrowed it down to the inclusion of any 
bibliography. Test case attached.




test_undo_2.3.lyx
Description: application/lyx


Re: Beta1 is slow on undo

2017-10-08 Thread racoon

On 08.10.2017 00:19, Scott Kostyshak wrote:

On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:

On 10/07/2017 12:09 PM, racoon wrote:

Hi,

I noticed that beta1 shows some slowness when undoing with some of my
documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
second to respond to it.

Did anyone notice this? I don't have a very fast computer though.


Yes, I have also seen that, and my machines are pretty fast.


I can't reproduce. My test case was to open the user guide, selected
all, delete, and undo. Both were instantaneous for me. Do you have a
better test case for me?


Yes, those documents are fine at my side as well. I'll try to send a 
test case soon.





Re: Beta1 is slow on undo

2017-10-07 Thread Richard Heck
On 10/07/2017 06:19 PM, Scott Kostyshak wrote:
> On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:
>> On 10/07/2017 12:09 PM, racoon wrote:
>>> Hi,
>>>
>>> I noticed that beta1 shows some slowness when undoing with some of my
>>> documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
>>> second to respond to it.
>>>
>>> Did anyone notice this? I don't have a very fast computer though.
>> Yes, I have also seen that, and my machines are pretty fast.
> I can't reproduce. My test case was to open the user guide, selected
> all, delete, and undo. Both were instantaneous for me. Do you have a
> better test case for me?

What I've seen is during normal operation. I make a large number of
edits and decide to undo all of them, basically holding down Ctrl-Z. It
is then much slower than doing the same thing with 2.2.x.

Richard



Re: Beta1 is slow on undo

2017-10-07 Thread Scott Kostyshak
On Sat, Oct 07, 2017 at 05:57:48PM +, Richard Heck wrote:
> On 10/07/2017 12:09 PM, racoon wrote:
> > Hi,
> >
> > I noticed that beta1 shows some slowness when undoing with some of my
> > documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
> > second to respond to it.
> >
> > Did anyone notice this? I don't have a very fast computer though.
> 
> Yes, I have also seen that, and my machines are pretty fast.

I can't reproduce. My test case was to open the user guide, selected
all, delete, and undo. Both were instantaneous for me. Do you have a
better test case for me?

Scott


signature.asc
Description: PGP signature


Re: Beta1 is slow on undo

2017-10-07 Thread Richard Heck
On 10/07/2017 12:09 PM, racoon wrote:
> Hi,
>
> I noticed that beta1 shows some slowness when undoing with some of my
> documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a
> second to respond to it.
>
> Did anyone notice this? I don't have a very fast computer though.

Yes, I have also seen that, and my machines are pretty fast.

Richard