Re: Master is slow
On Mon, May 13, 2019 at 10:35:54AM +0200, Jean-Marc Lasgouttes wrote: > Le 13/05/2019 à 07:11, Scott Kostyshak a écrit : > > Has the situation of Buffer::updateMacros improved in the last couple of > > years? If not, would it be worth considering tracking whether a document > > uses a macro? This way, users who do not use macros would not have the > > performance hit? > > I tried to improve the situation be removing a call to updateMacros, but > this turned out to crash LyX. So the call is back. This macro systems scares > me, but I am sure we can get rid of the quadratic loop in some way. I never > really took the time to write things down though. > > In any case, scary pieces of code should be on the top of the > things-to-rewrite list, even though we want to stop thinking about them :) Good to know. > > By the way, I personally find LyX to be fast for my needs. > > For me too. We could try to ask on the users' mailing list, maybe when 2.3.3 > is out (with the lbearing cache fix for windows) for stories about "LyX is > slow for me". True. Maybe after 2.4.0 would be a good time for that poll. Scott signature.asc Description: PGP signature
Re: Master is slow
Le 13/05/2019 à 07:11, Scott Kostyshak a écrit : Has the situation of Buffer::updateMacros improved in the last couple of years? If not, would it be worth considering tracking whether a document uses a macro? This way, users who do not use macros would not have the performance hit? I tried to improve the situation be removing a call to updateMacros, but this turned out to crash LyX. So the call is back. This macro systems scares me, but I am sure we can get rid of the quadratic loop in some way. I never really took the time to write things down though. In any case, scary pieces of code should be on the top of the things-to-rewrite list, even though we want to stop thinking about them :) By the way, I personally find LyX to be fast for my needs. For me too. We could try to ask on the users' mailing list, maybe when 2.3.3 is out (with the lbearing cache fix for windows) for stories about "LyX is slow for me". JMarc
Re: Master is slow
On Mon, Oct 24, 2016 at 06:08:59PM +0200, Jean-Marc Lasgouttes wrote: > Le 22/10/2016 à 19:39, Guillaume Munch a écrit : > > After improvements by Richard and Jean-Marc, GuiView::getStatus is down > > to 10% (mostly lyx::to_utf8) and there is no trace of tabs updating. > > Thanks for checking. > > > New bottlenecks are Buffer::updateMacros (25%, of course depends on > > the document) and nothing else looks really out of place. You can > > celebrate. > > Yes, this one is a sore point, especially for people who do not use macros. Has the situation of Buffer::updateMacros improved in the last couple of years? If not, would it be worth considering tracking whether a document uses a macro? This way, users who do not use macros would not have the performance hit? By the way, I personally find LyX to be fast for my needs. Scott signature.asc Description: PGP signature
Re: Opening User Guide on master is slow
Am Donnerstag, den 27.12.2018, 20:19 -0500 schrieb Scott Kostyshak: > On master, it seems to me that opening the User Guide is slow. Is > this a > known issue? I seem to remember some slowness coming from > layout2layout, > so maybe that is called on the modules and that is what makes it > slow? Or the loading of graphics? Jürgen > > Scott signature.asc Description: This is a digitally signed message part
Opening User Guide on master is slow
On master, it seems to me that opening the User Guide is slow. Is this a known issue? I seem to remember some slowness coming from layout2layout, so maybe that is called on the modules and that is what makes it slow? Scott signature.asc Description: PGP signature
Re: Master is slow
On 01.11.2016 19:14, racoon wrote: On 22.10.2016 19:39, Guillaume Munch wrote: Le 18/10/2016 à 21:44, Guillaume Munch a écrit : Profiling shows that calls to BufferParams::isExportableFormat are numerous and expensive when doing char-forward (33% of the total amount of CPU). This is called from GuiView::updateToolbars -> GuiView::getStatus. There is room for improvement, but this is not new behaviour apparently. I also found that calls to TabWorkArea::updateTabTexts are expensive and repeatedb. This amounts to 31% of the total amount of CPU, shared between QTabWidget::setTabText and QTabWidget::setTabIcon. TabWorkArea::updateTabTexts is connected to the signal GuiWorkArea::titleChanged. After improvements by Richard and Jean-Marc, GuiView::getStatus is down to 10% (mostly lyx::to_utf8) and there is no trace of tabs updating. New bottlenecks are Buffer::updateMacros (25%, of course depends on the document) and nothing else looks really out of place. You can celebrate. Daniel, is it still slow for you? Sorry for the late reply. I still have a hard time finding out when someone sends a message to the group without also answering to my email address. Yes, it is still slow. But it still seems to be in some kind of debug mode: there is a console in the background, Visual Studio says Build started: Project: lyx_version, Configuration: Debug Win32 Build started: Project: frontend_qt, Configuration: Debug Win32 etc. Install configuration: "Debug" I tried to uncheck/check the flags that have been suggested but it did not change those messages. Update on slowness. After installing Qt5.6.2 and using the latest master LyX seems now fine even though I still get the 'Install configuration: "Debug"' and the like from Visual Studio. Daniel
Re: Master is slow
On 22.10.2016 19:39, Guillaume Munch wrote: Le 18/10/2016 à 21:44, Guillaume Munch a écrit : Profiling shows that calls to BufferParams::isExportableFormat are numerous and expensive when doing char-forward (33% of the total amount of CPU). This is called from GuiView::updateToolbars -> GuiView::getStatus. There is room for improvement, but this is not new behaviour apparently. I also found that calls to TabWorkArea::updateTabTexts are expensive and repeatedb. This amounts to 31% of the total amount of CPU, shared between QTabWidget::setTabText and QTabWidget::setTabIcon. TabWorkArea::updateTabTexts is connected to the signal GuiWorkArea::titleChanged. After improvements by Richard and Jean-Marc, GuiView::getStatus is down to 10% (mostly lyx::to_utf8) and there is no trace of tabs updating. New bottlenecks are Buffer::updateMacros (25%, of course depends on the document) and nothing else looks really out of place. You can celebrate. Daniel, is it still slow for you? Sorry for the late reply. I still have a hard time finding out when someone sends a message to the group without also answering to my email address. Yes, it is still slow. But it still seems to be in some kind of debug mode: there is a console in the background, Visual Studio says Build started: Project: lyx_version, Configuration: Debug Win32 Build started: Project: frontend_qt, Configuration: Debug Win32 etc. Install configuration: "Debug" I tried to uncheck/check the flags that have been suggested but it did not change those messages. Daniel
Re: Master is slow
Le 22/10/2016 à 19:39, Guillaume Munch a écrit : After improvements by Richard and Jean-Marc, GuiView::getStatus is down to 10% (mostly lyx::to_utf8) and there is no trace of tabs updating. Thanks for checking. New bottlenecks are Buffer::updateMacros (25%, of course depends on the document) and nothing else looks really out of place. You can celebrate. Yes, this one is a sore point, especially for people who do not use macros. JMarc
Re: Master is slow
On 10/22/2016 01:39 PM, Guillaume Munch wrote: > Le 18/10/2016 à 21:44, Guillaume Munch a écrit : >> >> Profiling shows that calls to BufferParams::isExportableFormat >> are numerous and expensive when doing char-forward (33% of the total >> amount of CPU). This is called from GuiView::updateToolbars -> >> GuiView::getStatus. There is room for improvement, but this is not new >> behaviour apparently. >> >> I also found that calls to TabWorkArea::updateTabTexts are >> expensive and repeatedb. This amounts to 31% of the total amount of CPU, >> shared between QTabWidget::setTabText and QTabWidget::setTabIcon. >> TabWorkArea::updateTabTexts is connected to the signal >> GuiWorkArea::titleChanged. >> > > > After improvements by Richard and Jean-Marc, GuiView::getStatus is down > to 10% (mostly lyx::to_utf8) and there is no trace of tabs updating. Many of the to_utf8 calls are probably "FIXME Unicode", too. > New bottlenecks are Buffer::updateMacros (25%, of course depends on > the document) and nothing else looks really out of place. You can > celebrate. I've long wondered whether the updateMacros call in BufferView::processUpdateFlags is really necessary. As I say in a FIXME there: We call updateMacros in updateBuffer, and if the Buffer doesn't need updating, will the macros? I'm morally certain, at least, that we could at least include another flag that would tell us if they did need updating. But I don't know enough about the macro machinery to be sure when they do and when they do not. That said, if anyone is brave enough to do so, we could try commenting that line out and see what happens. Richard
Re: Master is slow
Le 18/10/2016 à 21:44, Guillaume Munch a écrit : Profiling shows that calls to BufferParams::isExportableFormat are numerous and expensive when doing char-forward (33% of the total amount of CPU). This is called from GuiView::updateToolbars -> GuiView::getStatus. There is room for improvement, but this is not new behaviour apparently. I also found that calls to TabWorkArea::updateTabTexts are expensive and repeatedb. This amounts to 31% of the total amount of CPU, shared between QTabWidget::setTabText and QTabWidget::setTabIcon. TabWorkArea::updateTabTexts is connected to the signal GuiWorkArea::titleChanged. After improvements by Richard and Jean-Marc, GuiView::getStatus is down to 10% (mostly lyx::to_utf8) and there is no trace of tabs updating. New bottlenecks are Buffer::updateMacros (25%, of course depends on the document) and nothing else looks really out of place. You can celebrate. Daniel, is it still slow for you?
Re: Master is slow
On 19.10.2016 07:08, racoon wrote: On 19.10.2016 07:03, racoon wrote: On 18.10.2016 21:44, Guillaume Munch wrote: Le 15/10/2016 à 11:39, racoon a écrit : Typing within the master's work area is slow on my computer (while it is fine in 2.2.2 and 2.1.5). Maybe this just has to do with some debugging running in the background or so? A minimal working example to reproduce the slowness could help. You can also try to profile your installation yourself with callgrind (you will have to adapt for windows the instructions at https://wiki.lyx.org/FAQ/FurtherHelp#profile) It is really as simple as I wrote. I just create an empty document and start typing quickly. LyX 2.2.2 can follow along, but the master starts lagging behind. Maybe there is something strange with debug going on? I am trying to figure it out on the other branch of this threat. By the way this did not start recently. I remember it being slow since I first time compiled it a while ago. I also noticed that my self-compiled LyX starts much slower. I guess this also points towards my compiled version just being much slower in general. Daniel
Re: Master is slow
On 19.10.2016 07:03, racoon wrote: On 18.10.2016 21:44, Guillaume Munch wrote: Le 15/10/2016 à 11:39, racoon a écrit : Typing within the master's work area is slow on my computer (while it is fine in 2.2.2 and 2.1.5). Maybe this just has to do with some debugging running in the background or so? A minimal working example to reproduce the slowness could help. You can also try to profile your installation yourself with callgrind (you will have to adapt for windows the instructions at https://wiki.lyx.org/FAQ/FurtherHelp#profile) It is really as simple as I wrote. I just create an empty document and start typing quickly. LyX 2.2.2 can follow along, but the master starts lagging behind. Maybe there is something strange with debug going on? I am trying to figure it out on the other branch of this threat. By the way this did not start recently. I remember it being slow since I first time compiled it a while ago.
Re: Master is slow
On 18.10.2016 21:44, Guillaume Munch wrote: Le 15/10/2016 à 11:39, racoon a écrit : Typing within the master's work area is slow on my computer (while it is fine in 2.2.2 and 2.1.5). Maybe this just has to do with some debugging running in the background or so? A minimal working example to reproduce the slowness could help. You can also try to profile your installation yourself with callgrind (you will have to adapt for windows the instructions at https://wiki.lyx.org/FAQ/FurtherHelp#profile) It is really as simple as I wrote. I just create an empty document and start typing quickly. LyX 2.2.2 can follow along, but the master starts lagging behind. Maybe there is something strange with debug going on? I am trying to figure it out on the other branch of this threat. Daniel
Re: Master is slow
On 18.10.2016 18:43, Kornel Benko wrote: Am Dienstag, 18. Oktober 2016 um 18:30:22, schrieb racoonOn 18.10.2016 10:13, Kornel Benko wrote: Am Dienstag, 18. Oktober 2016 um 09:58:14, schrieb Jean-Marc Lasgouttes Le 18/10/2016 à 09:55, racoon a écrit : On 18.10.2016 09:46, Jean-Marc Lasgouttes wrote: Le 15/10/2016 à 19:53, racoon a écrit : Yes, I think so. Does compiling in normal mode help to recover the original speed? Could you remind me how to compile in non-debug mode? Is that a setting in CMAKE that I have to uncheck or so? Kornel? Uwe? (I am an autoconf guy) JMarc Maybe this could help: -DLYX_DEBUG=OFF -DLYX_RELEASE=ON Kornel I have disabled LYX_DEBUG and LYX_RELEASE in cmake gui, generated and reconfigurated. It seems to be still the same (slow). Why disabling LYX_RELEASE? Sorry, I just wrote it wrongly but set it correctly. LYX_RELEASE is enabled. Maybe the VS output is helpful? 1>-- Build started: Project: lyx_version, Configuration: Debug Win32 -- 1> -- Git-hash = 120e84a 1> -- Created C:/LyX/LyX2.3.0-build/lyx_date.tmp 1> -- Created C:/LyX/LyX2.3.0-build/lyx_commit_hash.tmp 2>-- Build started: Project: INSTALL, Configuration: Debug Win32 -- 2> -- Install configuration: "Debug" No wonder, because LYX_RELEASE is disabled. Should have been -- Install configuration: "Release" See above. Also tried another run of cmake but it didn't help. Is there something else I have to uncheck? Maybe within VS? 2> -- Up-to-date: C:/LyX/LyX2.3.0-build/LYX_INSTALLED/bin/LyX.exe 2> -- Up-to-date: C:/LyX/LyX2.3.0-build/LYX_INSTALLED/bin/tex2lyx.exe 2> -- Up-to-date: C:/LyX/LyX2.3.0-build/LYX_INSTALLED/Resources/lyx2lyx/lyx2lyx_version.py 2> -- Up-to-date: C:/LyX/LyX2.3.0-build/LYX_INSTALLED/Resources/lyx2lyx/lyx2lyx == Build: 2 succeeded, 0 failed, 23 up-to-date, 0 skipped == Daniel Btw, I use Qt5.7 on linux and don't feel any slowness. Kornel
Re: Master is slow
Le 18/10/16 à 22:10, Richard Heck a écrit : I also found that calls to TabWorkArea::updateTabTexts are expensive and repeatedb. This amounts to 31% of the total amount of CPU, shared between QTabWidget::setTabText and QTabWidget::setTabIcon. TabWorkArea::updateTabTexts is connected to the signal GuiWorkArea::titleChanged. Could we here have some flag that told us whether anything has changed? I think that I removed such a test %-] Let me check. JMarc
Re: Master is slow
On 10/18/2016 03:44 PM, Guillaume Munch wrote: > Le 15/10/2016 à 11:39, racoon a écrit : >> Typing within the master's work area is slow on my computer (while it is >> fine in 2.2.2 and 2.1.5). Maybe this just has to do with some debugging >> running in the background or so? >> > > > Profiling shows that calls to BufferParams::isExportableFormat > are numerous and expensive when doing char-forward (33% of the total > amount of CPU). This is called from GuiView::updateToolbars -> > GuiView::getStatus. There is room for improvement, but this is not new > behaviour apparently. Yes, I've been meaning for a while to implement a simple cache here, but just haven't had time. That would help a lot. > I also found that calls to TabWorkArea::updateTabTexts are > expensive and repeatedb. This amounts to 31% of the total amount of CPU, > shared between QTabWidget::setTabText and QTabWidget::setTabIcon. > TabWorkArea::updateTabTexts is connected to the signal > GuiWorkArea::titleChanged. Could we here have some flag that told us whether anything has changed? Richard
Re: Master is slow
Le 15/10/2016 à 11:39, racoon a écrit : Typing within the master's work area is slow on my computer (while it is fine in 2.2.2 and 2.1.5). Maybe this just has to do with some debugging running in the background or so? Profiling shows that calls to BufferParams::isExportableFormat are numerous and expensive when doing char-forward (33% of the total amount of CPU). This is called from GuiView::updateToolbars -> GuiView::getStatus. There is room for improvement, but this is not new behaviour apparently. I also found that calls to TabWorkArea::updateTabTexts are expensive and repeatedb. This amounts to 31% of the total amount of CPU, shared between QTabWidget::setTabText and QTabWidget::setTabIcon. TabWorkArea::updateTabTexts is connected to the signal GuiWorkArea::titleChanged. A minimal working example to reproduce the slowness could help. You can also try to profile your installation yourself with callgrind (you will have to adapt for windows the instructions at https://wiki.lyx.org/FAQ/FurtherHelp#profile) Jean-Marc, could the calls to TabWorkArea::updateTabTexts have to do with your work on improved titles?
Re: Master is slow
Am Dienstag, 18. Oktober 2016 um 18:30:22, schrieb racoon> On 18.10.2016 10:13, Kornel Benko wrote: > > Am Dienstag, 18. Oktober 2016 um 09:58:14, schrieb Jean-Marc Lasgouttes > > > >> Le 18/10/2016 à 09:55, racoon a écrit : > >>> > >>> > >>> On 18.10.2016 09:46, Jean-Marc Lasgouttes wrote: > Le 15/10/2016 à 19:53, racoon a écrit : > > Yes, I think so. > > Does compiling in normal mode help to recover the original speed? > >>> > >>> Could you remind me how to compile in non-debug mode? Is that a setting > >>> in CMAKE that I have to uncheck or so? > >> > >> Kornel? Uwe? > >> > >> (I am an autoconf guy) > >> > >> JMarc > > > > Maybe this could help: > > -DLYX_DEBUG=OFF -DLYX_RELEASE=ON > > > > Kornel > > I have disabled LYX_DEBUG and LYX_RELEASE in cmake gui, generated and > reconfigurated. It seems to be still the same (slow). Why disabling LYX_RELEASE? > Maybe the VS output is helpful? > > 1>-- Build started: Project: lyx_version, Configuration: Debug Win32 > -- > 1> -- Git-hash = 120e84a > 1> -- Created C:/LyX/LyX2.3.0-build/lyx_date.tmp > 1> -- Created C:/LyX/LyX2.3.0-build/lyx_commit_hash.tmp > 2>-- Build started: Project: INSTALL, Configuration: Debug Win32 -- > 2> -- Install configuration: "Debug" No wonder, because LYX_RELEASE is disabled. Should have been -- Install configuration: "Release" > 2> -- Up-to-date: C:/LyX/LyX2.3.0-build/LYX_INSTALLED/bin/LyX.exe > 2> -- Up-to-date: C:/LyX/LyX2.3.0-build/LYX_INSTALLED/bin/tex2lyx.exe > 2> -- Up-to-date: > C:/LyX/LyX2.3.0-build/LYX_INSTALLED/Resources/lyx2lyx/lyx2lyx_version.py > 2> -- Up-to-date: > C:/LyX/LyX2.3.0-build/LYX_INSTALLED/Resources/lyx2lyx/lyx2lyx > == Build: 2 succeeded, 0 failed, 23 up-to-date, 0 skipped == > > Daniel Btw, I use Qt5.7 on linux and don't feel any slowness. Kornel signature.asc Description: This is a digitally signed message part.
Re: Master is slow
On 18.10.2016 10:13, Kornel Benko wrote: Am Dienstag, 18. Oktober 2016 um 09:58:14, schrieb Jean-Marc LasgouttesLe 18/10/2016 à 09:55, racoon a écrit : On 18.10.2016 09:46, Jean-Marc Lasgouttes wrote: Le 15/10/2016 à 19:53, racoon a écrit : Yes, I think so. Does compiling in normal mode help to recover the original speed? Could you remind me how to compile in non-debug mode? Is that a setting in CMAKE that I have to uncheck or so? Kornel? Uwe? (I am an autoconf guy) JMarc Maybe this could help: -DLYX_DEBUG=OFF -DLYX_RELEASE=ON Kornel I have disabled LYX_DEBUG and LYX_RELEASE in cmake gui, generated and reconfigurated. It seems to be still the same (slow). Maybe the VS output is helpful? 1>-- Build started: Project: lyx_version, Configuration: Debug Win32 -- 1> -- Git-hash = 120e84a 1> -- Created C:/LyX/LyX2.3.0-build/lyx_date.tmp 1> -- Created C:/LyX/LyX2.3.0-build/lyx_commit_hash.tmp 2>-- Build started: Project: INSTALL, Configuration: Debug Win32 -- 2> -- Install configuration: "Debug" 2> -- Up-to-date: C:/LyX/LyX2.3.0-build/LYX_INSTALLED/bin/LyX.exe 2> -- Up-to-date: C:/LyX/LyX2.3.0-build/LYX_INSTALLED/bin/tex2lyx.exe 2> -- Up-to-date: C:/LyX/LyX2.3.0-build/LYX_INSTALLED/Resources/lyx2lyx/lyx2lyx_version.py 2> -- Up-to-date: C:/LyX/LyX2.3.0-build/LYX_INSTALLED/Resources/lyx2lyx/lyx2lyx == Build: 2 succeeded, 0 failed, 23 up-to-date, 0 skipped == Daniel
Re: Master is slow
Am Dienstag, 18. Oktober 2016 um 09:58:14, schrieb Jean-Marc Lasgouttes> Le 18/10/2016 à 09:55, racoon a écrit : > > > > > > On 18.10.2016 09:46, Jean-Marc Lasgouttes wrote: > >> Le 15/10/2016 à 19:53, racoon a écrit : > >>> Yes, I think so. > >> > >> Does compiling in normal mode help to recover the original speed? > > > > Could you remind me how to compile in non-debug mode? Is that a setting > > in CMAKE that I have to uncheck or so? > > Kornel? Uwe? > > (I am an autoconf guy) > > JMarc Maybe this could help: -DLYX_DEBUG=OFF -DLYX_RELEASE=ON Kornel signature.asc Description: This is a digitally signed message part.
Re: Master is slow
Le 18/10/2016 à 09:55, racoon a écrit : On 18.10.2016 09:46, Jean-Marc Lasgouttes wrote: Le 15/10/2016 à 19:53, racoon a écrit : Yes, I think so. Does compiling in normal mode help to recover the original speed? Could you remind me how to compile in non-debug mode? Is that a setting in CMAKE that I have to uncheck or so? Kornel? Uwe? (I am an autoconf guy) JMarc
Re: Master is slow
On 18.10.2016 09:46, Jean-Marc Lasgouttes wrote: Le 15/10/2016 à 19:53, racoon a écrit : Yes, I think so. Does compiling in normal mode help to recover the original speed? Could you remind me how to compile in non-debug mode? Is that a setting in CMAKE that I have to uncheck or so? Daniel
Re: Master is slow
Le 15/10/2016 à 19:53, racoon a écrit : Yes, I think so. Does compiling in normal mode help to recover the original speed? JMarc On 15.10.2016 18:39, Jean-Marc Lasgouttes wrote: Did you compile in debug mode ?
Re: Master is slow
On 15.10.2016 20:27, Jean-Marc Lasgouttes wrote: Le 15/10/2016 à 19:53, racoon a écrit : Yes, I think so. This adds some run time checks in windows that can make things slower. Another thing to check: did you compile against Qt5 or Qt4? Qt5.
Re: Master is slow
On 15.10.2016 21:46, Guillaume Munch wrote: Le 15/10/2016 à 11:39, racoon a écrit : Typing within the master's work area is slow on my computer (while it is fine in 2.2.2 and 2.1.5). What is the qt version? Qt 5.6.1 Daniel
Re: Master is slow
Le 15/10/2016 à 11:39, racoon a écrit : Typing within the master's work area is slow on my computer (while it is fine in 2.2.2 and 2.1.5). What is the qt version?
Re: Master is slow
Le 15/10/2016 à 19:53, racoon a écrit : Yes, I think so. This adds some run time checks in windows that can make things slower. Another thing to check: did you compile against Qt5 or Qt4? From the top of my head, I cannot think of big changes in master that could slow things down. JMarc On 15.10.2016 18:39, Jean-Marc Lasgouttes wrote: Dis you compilé in debug mode ? Sorry, again my android french keyboard going wild. JMarc
Re: Master is slow
Yes, I think so. Daniel On 15.10.2016 18:39, Jean-Marc Lasgouttes wrote: Dis you compilé in debug mode ? JMarc Le 15 octobre 2016 11:39:55 GMT+02:00, racoona écrit : Typing within the master's work area is slow on my computer (while it is fine in 2.2.2 and 2.1.5). Maybe this just has to do with some debugging running in the background or so? Daniel
Re: Master is slow
Dis you compilé in debug mode ? JMarc Le 15 octobre 2016 11:39:55 GMT+02:00, racoona écrit : >Typing within the master's work area is slow on my computer (while it >is >fine in 2.2.2 and 2.1.5). Maybe this just has to do with some debugging > >running in the background or so? > >Daniel
Re: Master is slow
On 15.10.2016 16:18, Scott Kostyshak wrote: On Sat, Oct 15, 2016 at 11:39:55AM +0200, racoon wrote: Typing within the master's work area is slow on my computer (while it is fine in 2.2.2 and 2.1.5). Maybe this just has to do with some debugging running in the background or so? I haven't noticed this. Do you by chance have the code preview pane open in master? Valid comment especially given that I complained once about slowness and actually had it open. But (unfortunately?) not this time. Daniel
Re: Master is slow
On Sat, Oct 15, 2016 at 11:39:55AM +0200, racoon wrote: > Typing within the master's work area is slow on my computer (while it is > fine in 2.2.2 and 2.1.5). Maybe this just has to do with some debugging > running in the background or so? I haven't noticed this. Do you by chance have the code preview pane open in master? Scott signature.asc Description: PGP signature
Master is slow
Typing within the master's work area is slow on my computer (while it is fine in 2.2.2 and 2.1.5). Maybe this just has to do with some debugging running in the background or so? Daniel