Sigil-2.7.0 Released - Page 3

BeckyEbook · Yesterday, 06:20 AM

From my observations:
* We launch the first instance of Sigil (everything works normally, without delays).
* We launch the second instance of Sigil (the Preview window refreshes after a few seconds).
* Even after closing the first instance, the second instance (the only one currently running) is still "sluggish."

Windows 10 Pro 22H2

DiapDealer · Yesterday, 08:33 AM

I don't typically use multiple instances of Sigil so I probably just never noticed. But I can reproduce the sluggishness problem on Windows 10 as well. Rather then being "sluggish" though, It just seems like there's a delay built into the Preview refresh. Once it decides to go, it goes just as quickly as the first instance of Sigil.

I am noticing (in the task manager) that subsequent instances of Sigil are launching 2 QtWebEngineProcess processes instead of just one like the first Sigil launch does. It almost certainly has something to do with that.

KevinH · Yesterday, 09:41 AM

What priorities for the QWebEngine processes are you seeing in the Task Manager when you see the slowness? The priority will only impact the speed of Preview updating because its scheduled start will be delayed due to its lowered priority, but once scheduled/started, updating will be fast.

That is consistent with the sluggishness observed by BeckyEbook as well when the first instance of Sigil is closed.

I can turn off all use of disk based caching to see if that helps, but then nothing will be remembered (ala the Inspector not remembering its language settings, if you remember that bug report).

We have used all disk based caching in the past when it was broken with no issues, and the new WebProfileBuilder is supposed to prevent a disk cache from being reused by another process.

Please check out the priority of the QWebEngine processes in the task manager and let me know what priorities you are seeing.

It does appear strange that the second instance of Sigil is generating 2 QWebEngineProcess threads instead of the expected single one.

If you get a free moment, can you test the same thing on Linux as well. If so, I may be able to recreate it there.

Maybe we should be thinking about making both Windows, and Linux versions of Sigil, use the same multiple main window approach that MacOS and Microsoft Office (all flavours) uses.

Another thing to try is actually opening multiple browser program instances, each with multiple tabs instead of just new main windows and/or just new tabs to see how that responds on Windows.

KevinH

DiapDealer · Yesterday, 10:00 AM

Subsequent QtQwebEngineProcess threads are definitely launched with a "low" priority rather than "normal" but bumping the priority of those threads to "normal" or even "high" doesn't seem to have any effect on the delay in the Preview load.

KevinH · Yesterday, 10:13 AM

Yes bumping thread priority is hard to do across the huge set of threads created by Qt/Sigil.

Is there some way to force launch the second instance of Sigil at normal priority?

I thought there was a way to set something in task manager to force a program to launch in normal priority (ie. turn off efficiency mode), if I remember doing it permanently requires regedit.

DiapDealer · Yesterday, 10:21 AM

Sigil itself is always launched at a normal priority. It's one (or sometimes both) of the associated QtWebEngineProcess threads that launch as low priority. I'm typically only seeing 2 or 3 threads associated with each Sigil instance on my Windows 10 laptop. Making sure all of those threads are normal (or high) priority doesn't seem to have any effect on the lag.

DiapDealer · Yesterday, 10:28 AM

Even the initial instance of Sigil can have a QtWebEngineProcess thread with a low priority without causing any lag. I'm not really seeing much of a difference in thread priorities on the second or third Sigil instances when it boils down to it.

KevinH · Yesterday, 10:36 AM

There are 20 or so threads for the Sigil process on my Mac, but most are just worker threads.

Windows must be different somehow. I will modify our WebProfileManager to never use disk cache just as a test so we can test the disk cache contention hypotheses.

DiapDealer · Yesterday, 10:48 AM

I can easily create a batch file to make sure Sigil always starts with a particular priority, but nothing I do seems to affect the priority of Sigil's spawned QtWebEngineProcess threads.

KevinH · Yesterday, 10:54 AM

In task manager, do you see any differences at all between the first and second QWebEngineProcces threads? There is an "efficiency mode" of some sort that overrides priorities in Windows.

I will push a version of Webprofile manager that never uses disk caches to master with deploy to test that hypothesis with.

KevinH · Yesterday, 11:12 AM

Okay, I just made a change to WebProfileMgr.cpp to force use of memory only caches and pushed it to master with deploy.

When it completes, would you please test running 2 versions of Sigil and look for Preview delays in the second version again.

If they go away, that would support Kovid's theory about file related locking in disk caches creating issues.

If that turns out to me true, I strongly think the only solution is to go to a multi-main window approach as used by Office (Word, Excel, etc) on all platforms and that has long been used by Sigil for MacOS.

Thoughts?

DiapDealer · Yesterday, 12:22 PM

The memory-only caches definitely eliminated the delays for me. I wonder if we could track down which QtWebEngine disk cache is leaking through our memory-cache only strategy for subsequent Sigil instances and patch it on our Windows Qt?

https://github.com/kovidgoyal/bypy/b...qt_base.py#L65

KevinH · Yesterday, 12:22 PM

Did changing it to use only memory caches help?

DiapDealer · Yesterday, 12:37 PM

Yes. Sorry if that wasn't clear. It definitely eliminated the Preview delays for me.

KevinH · Yesterday, 12:57 PM

@DiapDealer,

I just missed your earlier reply. The version you just tested uses full Off The Record caches. I just pushed with deploy a version that uses only memory caches with a named cache folder.

Would you please run the same test when it completes so that we can see if it is the naming of the cache folder that causes the conflict, or if just using a memory cache (not fully OTR) is the culprit.

Thanks

ps. either way I think Kovid's theory is the right one. We just have to figure out how to work around it on Windows.

On MacOS no issues because of the multi-main window design. And I just tested on Linux and there are no slowdowns at all running multiple instances in loading Preview.

So this cache file lock contention is the issue, then it only exists on Windows (not Mac or Linux).

Yesterday, 09:41 AM	#33
KevinH Sigil Developer Posts: 9,150 Karma: 6565346 Join Date: Nov 2009 Device: many	What priorities for the QWebEngine processes are you seeing in the Task Manager when you see the slowness? The priority will only impact the speed of Preview updating because its scheduled start will be delayed due to its lowered priority, but once scheduled/started, updating will be fast. That is consistent with the sluggishness observed by BeckyEbook as well when the first instance of Sigil is closed. I can turn off all use of disk based caching to see if that helps, but then nothing will be remembered (ala the Inspector not remembering its language settings, if you remember that bug report). We have used all disk based caching in the past when it was broken with no issues, and the new WebProfileBuilder is supposed to prevent a disk cache from being reused by another process. Please check out the priority of the QWebEngine processes in the task manager and let me know what priorities you are seeing. It does appear strange that the second instance of Sigil is generating 2 QWebEngineProcess threads instead of the expected single one. If you get a free moment, can you test the same thing on Linux as well. If so, I may be able to recreate it there. Maybe we should be thinking about making both Windows, and Linux versions of Sigil, use the same multiple main window approach that MacOS and Microsoft Office (all flavours) uses. Another thing to try is actually opening multiple browser program instances, each with multiple tabs instead of just new main windows and/or just new tabs to see how that responds on Windows. KevinH Last edited by KevinH; Yesterday at 09:52 AM.

Yesterday, 11:12 AM	#41
KevinH Sigil Developer Posts: 9,150 Karma: 6565346 Join Date: Nov 2009 Device: many	Okay, I just made a change to WebProfileMgr.cpp to force use of memory only caches and pushed it to master with deploy. When it completes, would you please test running 2 versions of Sigil and look for Preview delays in the second version again. If they go away, that would support Kovid's theory about file related locking in disk caches creating issues. If that turns out to me true, I strongly think the only solution is to go to a multi-main window approach as used by Office (Word, Excel, etc) on all platforms and that has long been used by Sigil for MacOS. Thoughts? Last edited by KevinH; Yesterday at 12:07 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Sigil-0.9.10 Released	DiapDealer	Sigil	149	11-19-2018 11:20 PM
Sigil-0.9.2 Released	KevinH	Sigil	14	01-11-2016 04:11 AM
Sigil-0.8.900 released for testing - Wait for Sigil-0.8.901	KevinH	Sigil	106	10-04-2015 11:41 AM
Sigil 0.8.4 Released	user_none	Sigil	3	02-14-2015 06:38 PM
Sigil 0.7.2 Released	user_none	Sigil	40	06-25-2013 12:35 AM

Yesterday, 06:20 AM	#31
BeckyEbook Guru Posts: 913 Karma: 3501166 Join Date: Jan 2017 Location: Poland Device: Various	From my observations: * We launch the first instance of Sigil (everything works normally, without delays). * We launch the second instance of Sigil (the Preview window refreshes after a few seconds). * Even after closing the first instance, the second instance (the only one currently running) is still "sluggish." Windows 10 Pro 22H2

Yesterday, 08:33 AM	#32
DiapDealer Grand Sorcerer Posts: 28,950 Karma: 208522836 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I don't typically use multiple instances of Sigil so I probably just never noticed. But I can reproduce the sluggishness problem on Windows 10 as well. Rather then being "sluggish" though, It just seems like there's a delay built into the Preview refresh. Once it decides to go, it goes just as quickly as the first instance of Sigil. I am noticing (in the task manager) that subsequent instances of Sigil are launching 2 QtWebEngineProcess processes instead of just one like the first Sigil launch does. It almost certainly has something to do with that.

Yesterday, 10:00 AM	#34
DiapDealer Grand Sorcerer Posts: 28,950 Karma: 208522836 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Subsequent QtQwebEngineProcess threads are definitely launched with a "low" priority rather than "normal" but bumping the priority of those threads to "normal" or even "high" doesn't seem to have any effect on the delay in the Preview load.

Yesterday, 10:13 AM	#35
KevinH Sigil Developer Posts: 9,150 Karma: 6565346 Join Date: Nov 2009 Device: many	Yes bumping thread priority is hard to do across the huge set of threads created by Qt/Sigil. Is there some way to force launch the second instance of Sigil at normal priority? I thought there was a way to set something in task manager to force a program to launch in normal priority (ie. turn off efficiency mode), if I remember doing it permanently requires regedit.

Yesterday, 10:21 AM	#36
DiapDealer Grand Sorcerer Posts: 28,950 Karma: 208522836 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Sigil itself is always launched at a normal priority. It's one (or sometimes both) of the associated QtWebEngineProcess threads that launch as low priority. I'm typically only seeing 2 or 3 threads associated with each Sigil instance on my Windows 10 laptop. Making sure all of those threads are normal (or high) priority doesn't seem to have any effect on the lag.

Yesterday, 10:28 AM	#37
DiapDealer Grand Sorcerer Posts: 28,950 Karma: 208522836 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Even the initial instance of Sigil can have a QtWebEngineProcess thread with a low priority without causing any lag. I'm not really seeing much of a difference in thread priorities on the second or third Sigil instances when it boils down to it.

Yesterday, 10:36 AM	#38
KevinH Sigil Developer Posts: 9,150 Karma: 6565346 Join Date: Nov 2009 Device: many	There are 20 or so threads for the Sigil process on my Mac, but most are just worker threads. Windows must be different somehow. I will modify our WebProfileManager to never use disk cache just as a test so we can test the disk cache contention hypotheses.

Yesterday, 10:48 AM	#39
DiapDealer Grand Sorcerer Posts: 28,950 Karma: 208522836 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I can easily create a batch file to make sure Sigil always starts with a particular priority, but nothing I do seems to affect the priority of Sigil's spawned QtWebEngineProcess threads.

Yesterday, 10:54 AM	#40
KevinH Sigil Developer Posts: 9,150 Karma: 6565346 Join Date: Nov 2009 Device: many	In task manager, do you see any differences at all between the first and second QWebEngineProcces threads? There is an "efficiency mode" of some sort that overrides priorities in Windows. I will push a version of Webprofile manager that never uses disk caches to master with deploy to test that hypothesis with.

Yesterday, 12:22 PM	#42
DiapDealer Grand Sorcerer Posts: 28,950 Karma: 208522836 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	The memory-only caches definitely eliminated the delays for me. I wonder if we could track down which QtWebEngine disk cache is leaking through our memory-cache only strategy for subsequent Sigil instances and patch it on our Windows Qt? https://github.com/kovidgoyal/bypy/b...qt_base.py#L65

Yesterday, 12:37 PM	#44
DiapDealer Grand Sorcerer Posts: 28,950 Karma: 208522836 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Yes. Sorry if that wasn't clear. It definitely eliminated the Preview delays for me.

Yesterday, 12:57 PM	#45
KevinH Sigil Developer Posts: 9,150 Karma: 6565346 Join Date: Nov 2009 Device: many	@DiapDealer, I just missed your earlier reply. The version you just tested uses full Off The Record caches. I just pushed with deploy a version that uses only memory caches with a named cache folder. Would you please run the same test when it completes so that we can see if it is the naming of the cache folder that causes the conflict, or if just using a memory cache (not fully OTR) is the culprit. Thanks ps. either way I think Kovid's theory is the right one. We just have to figure out how to work around it on Windows. On MacOS no issues because of the multi-main window design. And I just tested on Linux and there are no slowdowns at all running multiple instances in loading Preview. So this cache file lock contention is the issue, then it only exists on Windows (not Mac or Linux).