Sigil-0.9.12 Released

[DiapDealer]

Originally Posted by BetterRed

Added: Should SIGIL_PREFS_DIR relocate the sigil-ebook or the sigil-ebook\sigil directory?

Sigil expects the Sigil.ini file to be in the directory specified by SIGIL_PREFS_DIR (or it will create a default one there if there's not one), so it would be the equivalent of the sigil-ebook\sigil directory. But it can be named anything.

Originally Posted by BetterRed

[I suggest a locked Sticky Thread at MR - Sigil Essentials. Somewhere to put the little things - env-vars, command line options, pre-requisites etc.

BR

We'll see. I'm trying to grow Sigil's Github Wiki little by little, so I may put info like that there.

[BetterRed]

Originally Posted by DiapDealer

... But it can be named anything.

like C:\_AppData\Sigil\Prefs

BR

[DiapDealer]

Remember that if you're planning to run two Sigil installations under the same user account, you'll need to set the variable in a cmd script that launches Sigil for one of the installs. Otherwise both installs will use the same directory defined by the env var if it's defined globally (or if it's a user env var).

[RbnJrg]

Originally Posted by DiapDealer

What are those issues (aside from your concerns over memory increases measured in 100s of MBs)?

If there are still major performance issues after a clean install with no saved preferences at all (and by major, I mean seeing "Not Responding" messages), then we need to start looking at issues with particular video drivers and other installed software. The fact of the matter is: there are lots people using the latest Sigil on Windows 10 and Windows 7 who are not experiencing any of these major performance issues. The number of those who are (and have reported them) is extremely low. This suggests that the issue does not lie with Sigil per se, but perhaps with issues that Sigil's new version of Qt has with particular hardware drivers or software on the machines that are having difficulty.

Well, regrettably, I had to downgrade to Sigil 0.9.10 It's practicably impossible for me to open two instances of Sigil 0.9.12; the program takes (the two instances) about 1.4GB of memory after a half an hour of work and Sigil becames slow and with many "Not respond" messages. With Sigil 0.9.10 that didn't happen (and is not happening). Maybe the new version of Qt is eating a lot of memory.

[DiapDealer]

Originally Posted by RbnJrg

Maybe the new version of Qt is eating a lot of memory.

No The likely problem is a) Your ini files were corrupted, or b) the new version of Qt has an issue with some software/driver on your system.

If your problem persists after starting from a fresh install (with fresh preferences) of Sigil 0.9.12, then we need to figure out what video driver or software package is causing the issue. We can't do that if everyone runs back to 0.9.10 or insists on declaring their own unsubstantiated prognoses.

[RbnJrg]

Originally Posted by DiapDealer

No The likely problem is a) Your ini files were corrupted, or b) the new version of Qt has an issue with some software/driver on your system.

If your problem persists after starting from a fresh install (with fresh preferences) of Sigil 0.9.12,...

Yes, did run Sigil 0.9.12 from a fresh install and without any .ini files present (in the Sigil's Preference folder).

...then we need to figure out what video driver or software package is causing the issue. We can't do that if everyone runs back to 0.9.10 or insists on declaring their own unsubstantiated prognoses.

Ok, you know Sigil better than me. But, what can I do? I can't work with the new Sigil release, so I run back to 0.9.10 by need.

[KevinH]

Understood. But please when you get a free moment, start again completely clean with empty ini files and things. Then when the huge slowdown hits, please zip up your sigil.ini, sigil_searches.ini, and sigil_clips.ini and post them here if you would.

I have experienced the huge slowdown on MacOS and it was when I invoked saved searches. It turns out my sigil_searches.ini was filled with garbage when it happened. So we are trying to figure out how that file or other ini files gets corrupted without running an old version of Sigil at the same time. Also please make sure you have only one instance of Sigil running in the TaskManager. Perhaps having multiple Sigils open, even if all the same version causes issues? We are still unsure and are hoping that any corruption in the ini files will give us some idea of what is going on.

Thanks!

KevinH

[RbnJrg]

Originally Posted by KevinH

Understood. But please when you get a free moment, start again completely clean with empty ini files and things. Then when the huge slowdown hits, please zip up your sigil.ini, sigil_searches.ini, and sigil_clips.ini and post them here if you would.

Ok. I'll do that and I'll post here my ini files (.ini files from Sigil 0.9.12).

Perhaps having multiple Sigils open, even if all the same version causes issues? We are still unsure and are hoping that any corruption in the ini files will give us some idea of what is going on.

The two instances of Sigil opened were of the same version: 0.9.12. And as I said, after half and hour of work, between both of them, the Task Manager reported a memory used of about 1.4GB

And thanks to you and Diap for your hard work!

[DiapDealer]

Originally Posted by RbnJrg

The two instances of Sigil opened were of the same version: 0.9.12. And as I said, after half and hour of work, between both of them, the Task Manager reported a memory used of about 1.4GB

Two instances with default INIs? Or had you already copied your old preferences back? That's the distinction I'm trying to make. Is Sigil using that much memory with the default INIs that are created with a fresh install, or are you copying your INIs back to gain access to your saved searches and such?

[Mark Nord]

Originally Posted by DiapDealer

Two instances with default INIs? Or had you already copied your old preferences back? That's the distinction I'm trying to make. Is Sigil using that much memory with the default INIs that are created with a fresh install, or are you copying your INIs back to gain access to your saved searches and such?

Hello Doug,
Current Sigil 0.9.12 32 & 64 bit using QT5.11.2 are using up memory if the preview Widget is shown, as RbnJrg reported in an earlier post.

I would have accepted Kevins and your replies about the memory-usage as to be expected and have silently revert to 0.9.9, but as Kevin is asking to track this down, here are my observations:
I did a clean install of Sigil 0.9.12 64bit under Windows 7 64 bit classic theme.
Both program-folder and preferences were renamed ahead of installation.
Fireed up Sigil, loaded a epub, messed around with it.
Memory-Usage in task-manger remained stable.
Pressed F10, as with initial settings, Preview isn't shown. Did some more messing around, changing between open tabs, memory usage climbed and climbed.
This happed with and without using S&R. Just example searches like join paragraph. (no own settings are copied over).
Pressed F10 again, the memory-usage remained stable at the high level but didn't increase any further.

Then I did another clean install of your legacy build 0.9.12 using QT5.6 and wounder what? There is a stable low memory foot-print even with the preview Widget open.
You will find the same with any Sigil version using QT5.6.
(I'm just wondering about the statements the high memory usage while changing tabs would to be expected, but you are the developers, so it is not me to judge.)

So, beside of an possible problem converting *.inis to UTF-8, which I also noticed. Once changing all dashes to some weird 3 char code not alone in *.ini but also in the xhtml files in an open epub, I suggest looking into the usage of the preview Widget under Windows and QT 5.11.2.

For the time being I will roll with the legacy build.

Sincerely
Mark

[RbnJrg]

Originally Posted by DiapDealer

Two instances with default INIs? Or had you already copied your old preferences back? That's the distinction I'm trying to make. Is Sigil using that much memory with the default INIs that are created with a fresh install, or are you copying your INIs back to gain access to your saved searches and such?

Hi Diap;

First at all, I cleaned all traced of previous versions of Sigil, .ini files included). After that I made a fresh installation of Sigil 0.9.12; the program created new .ini files. After starting for first time Sigil (that is, after the new installation), I changed some thing in "Preferences..." (languages, dictionary, size of icons, a couple of things more). In no way I copied material from my old .inis in the new ones. I restarted Sigil (so changes take effect) and I started to work and I load an epub I'm working on. After five ten minutes I started a new instance of Sigil to open an epub from where I was to copy some code. I continued working of that way, by seeking code in one instance of Sigil to paste inside the other, and to see how I had resolved some situations in previous work. After half and hour Sigil became slow and not responsive. I watched in Task Manager and between both instance opened of Sigil were using about 1.4GB of memory. The epubs had many images, some custom fonts and many .xhtml files but in the past I worked with similar files and I didn't have any trouble to have two (or more) instance of Sigil opened. Today I'm not working but tomorrow I'll do the test that Kevin said to me and I'll post here my .ini files.

[DiapDealer]

Originally Posted by Mark Nord

Hello Doug,
Current Sigil 0.9.12 32 & 64 bit using QT5.11.2 are using up memory if the preview Widget is shown, as RbnJrg reported in an earlier post.

I would have accepted Kevins and your replies about the memory-usage as to be expected and have silently revert to 0.9.9, but as Kevin is asking to track this down, here are my observations:
I did a clean install of Sigil 0.9.12 64bit under Windows 7 64 bit classic theme.
Both program-folder and preferences were renamed ahead of installation.
Fireed up Sigil, loaded a epub, messed around with it.
Memory-Usage in task-manger remained stable.
Pressed F10, as with initial settings, Preview isn't shown. Did some more messing around, changing between open tabs, memory usage climbed and climbed.
This happed with and without using S&R. Just example searches like join paragraph. (no own settings are copied over).
Pressed F10 again, the memory-usage remained stable at the high level but didn't increase any further.

Then I did another clean install of your legacy build 0.9.12 using QT5.6 and wounder what? There is a stable low memory foot-print even with the preview Widget open.
You will find the same with any Sigil version using QT5.6.
(I'm just wondering about the statements the high memory usage while changing tabs would to be expected, but you are the developers, so it is not me to judge.)

So, beside of an possible problem converting *.inis to UTF-8, which I also noticed. Once changing all dashes to some weird 3 char code not alone in *.ini but also in the xhtml files in an open epub, I suggest looking into the usage of the preview Widget under Windows and QT 5.11.2.

For the time being I will roll with the legacy build.

Sincerely
Mark

I understand that many want to use Task Manager's reported memory usage as an indicator of a problem, but I'm really only interested in performance issues that are experienced and not merely assumed by watching the "meter climb".

With the clean install and the default INIs, did you experience actual slowdowns? Did Sigil become less and less usable? Did you see any "Not responding messages", or did you merely see the numbers increasing in Task Manager?

I would really rather that testers leave Task Manager out of the equation completely.

I'm using 0.9.12 on both Windows 7 and Windows 10 and I have yet to experience any massive slowdowns or encounter any "Not Responding" messages. I'm not trying to brush reports off as "Works for me!" I know there are issues. I'm just trying to make it clear that that means it can't be as simple as Qt5.11.2, bad ... Qt5.6.2, good.

[DiapDealer]

Originally Posted by RbnJrg

Hi Diap;

First at all, I cleaned all traced of previous versions of Sigil, .ini files included). After that I made a fresh installation of Sigil 0.9.12; the program created new .ini files. After starting for first time Sigil (that is, after the new installation), I changed some thing in "Preferences..." (languages, dictionary, size of icons, a couple of things more). In no way I copied material from my old .inis in the new ones. I restarted Sigil (so changes take effect) and I started to work and I load an epub I'm working on. After five ten minutes I started a new instance of Sigil to open an epub from where I was to copy some code. I continued working of that way, by seeking code in one instance of Sigil to paste inside the other, and to see how I had resolved some situations in previous work. After half and hour Sigil became slow and not responsive. I watched in Task Manager and between both instance opened of Sigil were using about 1.4GB of memory. The epubs had many images, some custom fonts and many .xhtml files but in the past I worked with similar files and I didn't have any trouble to have two (or more) instance of Sigil opened. Today I'm not working but tomorrow I'll do the test that Kevin said to me and I'll post here my .ini files.

Thanks for getting back to me on that.

[DiapDealer]

Also keep in mind that using the default ini files is no guarantee that those defaults aren't getting corrupted as well. We clearly haven't tracked down all the possibilities that can cause ini corruption, so something you do as part of your regular routine (that we haven't stumbled across yet) could have already corrupted those default preference files.

The one thing we know for sure is that ini file corruption DOES cause massive performance issue with the recent versions.

[DiapDealer]

Originally Posted by RbnJrg

I changed some thing in "Preferences..." (languages, dictionary, size of icons, a couple of things more).

Can you be a little more specific about the changes you made here? I just want to rule out any possibility of corruption being caused by even the simplest things that people do with Sigil that I may not do.