Memory use and sluggish response

[exaltedwombat]

Originally Posted by lumpynose

Try the suggestion from theducks and close the Preview pane.

Thanks for the suggestion. But closing then re-opening it doesn't help, and I really NEED the Preview pane...


I'm cleaning up a conversion from PDF. The code's pretty clean, but I'm using Ctrl-Space a lot to strip unwanted paragraph breaks, Ctrl-C/Ctrl-V to add missing ones, Clips to surround a paragraph with formatting code... Everything except actually inputting text really!

[DiapDealer]

And please ... try to separate high memory usage, from sluggishness. In fact for the purposes of providing steps to reproduce, do me a favor and stop looking at or reporting memory usage. It's not at all helpful. Sigil on Windows can use a crap-ton of memory and still be completely responsive.

I can't get Sigil 0.9.13 to bog down on any of my Windows 10 machines--physical or virtual. The only time I had horrific performance issues on Windows 10 is when I somehow managed to accidentally assign Windows compatibility settings to Sigil.exe.

It's all really kind of moot anyway, because the next release of Sigil (with webkit) has had extensive work done to reduce the memory footprint. We've had some good reports from beta testers (who were experiencing severe performance issues) that while maybe not completely eliminated, the sluggishness they were experiencing was greatly reduced. And after that, we switch to webengine instead of webkit. Early testing there indicates no performance issues.

[exaltedwombat]

OK, thanks. The high memory use is a red herring then?

Looking forward to trying the next release. Fingers crossed...

[lumpynose]

Originally Posted by exaltedwombat

Thanks for the suggestion. But closing then re-opening it doesn't help, and I really NEED the Preview pane...

Try closing the Preview pane and then quiting Sigil and starting it, so that it starts with it closed. It seemed to not get sluggish on me in that case. But I'm like you and rely on it so it's a short term solution.

[lumpynose]

Originally Posted by KevinH

So does your epub have svg image files inside its Images folder?

Does your epub have embedded fonts which seems to cause fontcache leaks on *some* Windows machines?

Are you using a particular feature of Sigil repeatedly that might help us reproduce the issue? Things like Regular Expression Search and Replace, Spellchecking repeatedly, running Reports repeatedly, Using Clips repeatedly, splitting or merging of html files repeatedly, etc? Anything at all that we might try to see if we can reproduce what you are seeing.

I've now deleted it but I did have 1 svg in my Images folder. It wasn't being used. The only image used is png for the cover page.

No embedded fonts.

I'm mostly doing normal searches, sometimes on All HTML files, sometimes on Current file, and using ctl-v to paste the same thing over and over; e.g. the nbsp numeric entity or the emspace numeric entity, or the ellipsis numeric entity. I'm only working in epub3 if that makes any difference.

[lumpynose]

When I start a new chapter, so to speak, I right click on an existing chapter in the Book Browser and do Add Copy. Then a Rename. Which reminded me, someone else asked for binding/mapping F2 to Rename and since the Book View is going away that'll free F2.

[lumpynose]

Originally Posted by exaltedwombat

I'm cleaning up a conversion from PDF. The code's pretty clean, but I'm using Ctrl-Space a lot to strip unwanted paragraph breaks, Ctrl-C/Ctrl-V to add missing ones, Clips to surround a paragraph with formatting code... Everything except actually inputting text really!

That's similar to what I'm doing. I'm working with PDF scans of old magazines from archive.org where they contain the OCR'd text (SumatraPDF will save just the text with Save As).

Sometimes they have an empty line between paragraphs, sometimes not. But it starts as a big hunk of text between the body and /body tags; no html tags. I thought body didn't allow text directly, that it needs to be in a p, div, etc. although epubcheck doesn't complain.

[BetterRed]

Originally Posted by lumpynose

Which reminded me, someone else asked for binding/mapping F2 to Rename and since the Book View is going away that'll free F2.

No need to wait, you can change it now, just take F2 away from Toggle Book/Code View, or change to something else, and give F2 to Rename, viz:



BR

[lumpynose]

Originally Posted by BetterRed

No need to wait, you can change it now, just take F2 away from Toggle Book/Code View, or change to something else, and give F2 to Rename, viz:

Attachment 171828

BR

Wow, thanks. I never think of these things. Old age I guess.

[DiapDealer]

Originally Posted by exaltedwombat

OK, thanks. The high memory use is a red herring then?

Looking forward to trying the next release. Fingers crossed...

Not a red herring per se, but people tend to get hung up on micro-monitoring the memory usage instead of the actual performance. Sluggish performance will no doubt coincide with high memory usage, but there can also be quite high memory usage with no perceivable performance issue. And the bottom line is that the version of webkit in 0.9.13 is going to cause Preview to use more memory than it did in older versions of Sigil regardless.

[lumpynose]

The last time it was sluggish for me it wasn't using a lot of memory. I've since kept the Preview window closed and that seems to have cured the problem. Surprisingly, I can survive without the Preview window.

[KevinH]

FWIW, the Preview window uses QtWebkit as does BookView. This is the item most effected by CFG and antivirus/AI butting in.

[exaltedwombat]

Originally Posted by DiapDealer

Not a red herring per se, but people tend to get hung up on micro-monitoring the memory usage instead of the actual performance. Sluggish performance will no doubt coincide with high memory usage, but there can also be quite high memory usage with no perceivable performance issue. And the bottom line is that the version of webkit in 0.9.13 is going to cause Preview to use more memory than it did in older versions of Sigil regardless.

There's micro-monitoring. And there's watching an application's menory use start at 230MB and, over a half-hour editing session, ramp up to over 3GB (with no sign of having reached a ceiling)!

[DiapDealer]

Originally Posted by exaltedwombat

There's micro-monitoring. And there's watching an application's menory use start at 230MB and, over a half-hour editing session, ramp up to over 3GB (with no sign of having reached a ceiling)!

Yes there is. And I don't give a tinker's damn about either of them. I only care that Sigil has slowed way down and/or stopped responding. The actual amount of memory being consumed is utterly worthless from a debugging standpoint.