Sigil-1.6.0 Released

[DiapDealer]

And in Code View, I would expect "sigil_split_marker" to appear to be just as light/dark as any other html attribute value. They're all set by the same preference.

[brent63]

Thank you,

A little tweaking, and my new borders look great.

Brent

[hobnail]

This new version is blazing fast compared to the previous one. My computer is a beast; 16 cores/32 threads, 64 gig of ram, and the previous version ran like molasses.

[Tex2002ans]

Originally Posted by DiapDealer

I'd love to hear from those who were experiencing performance issues with the 1.4 and 1.5 series. There were a lot of performance-based changes in 1.6.

Absolutely fantastic performance improvements. Reports, Syntax Highlighting, Preview.

But there have been a few regressions introduced along the way too.

One Spellcheck List issue was already adjusted for next release—1.6.1:

- "In spellcheck do FindSelectedWord only if double-clicked to speed paging"

* * *

The Issue

When used on a very large EPUB (~1.6 million words), Tools > Spellcheck > Spellcheck was sluggish, with noticeable delays between clicks/highlights.

These were the timings in my VM:

- Sigil 1.6.0: ~1.4 seconds
- Sigil 1.5.1: ~1.4 seconds
- Sigil 0.9.14: <0.5 seconds
- Calibre 5.19: Instant

Note: In your typical-sized ebook, these steps barely take a perceivable amount of time.

VM Note: Windows 10 + 2 cores + on an external hard drive.

* * *

If you need an enormous EPUB (~1.3 million words) to poke around in, there's the same one I mentioned in my "monolithic single file" report:

https://mises.org/library/complete-l...orum-1969-1984

If you want it even bigger, just EPUB Merge it with another large ebook.

The Steps

While in Spellcheck List (Tools > Spellcheck > Spellcheck)...

Sigil pre-1.6.1

1. Single-click a word in the list. It jumps to the word within Code View.

2. Press Page Down/Up OR single-click any word.

(#.## seconds delay to find/jump within Code View.)

Page Down multiple times, and the delay hits every single time as Sigil searches through Code View.

Sigil 1.6.1+

To mitigate some of this, we settled on:

1. Double-click a word jumps to the word within Code View.

2. Press Page Down/Up OR single-click another word. No jump in Code View.

This allows you to easily make all your adjustments directly in Spellcheck List window (sort columns, Change Selected Word To, Add To Dictionary, [...]) without the need to mess with the code.

Side Note: This double-click jump + single-click stay is the way Calibre's Spellcheck List already works.

* * *

Note: KevinH tested this and couldn't reproduce. No/barely any slowness. Also seems like it would be a huge amount of overhaul for fractional gains.

Here was his explanation to me via PM:

Originally Posted by KevinH

As for lookup speed, my tests were not consistent with what you are seeing at all. The longest pause was clicking on a word that was misspelled only near the end of the book when current CV was open at the top of the book timed repeatedly to be was well under 1 second. Double-clicking on random misspelled words was often instantaneous depending on how far forward in the book it first appears.

All of these tests were done with your posted test case.

There really is no way to speed this up without doing the check in parallel across all xhtml files at once, but then sorting it to keep order, and then needing to cache the results for next time. Unfortunately a single IgnoreAll or ReplaceAll would invalidate the cache as would any other changes made.

It is just not worth the overhead unless I wanted to build a list of all places with that word and show the list with some limited context for each time the word was found. And then walk that list. The first find would then take longer while the follow-on for the next in the list would be much faster.

So a sub one second worst case lookup on a huge complex epub with random lookups generally much faster is okay in my book versus the added code complexity and overhead/bookkeeping needed for just incremental improvements unnoticeable with normal length epubs.

Any of you who have an under-powered device sitting around... maybe test some of these steps too. It'll probably be more noticeable compared to our super fast CPUs/SSDs.

... Although at this point, we're niggling over 1 second... Plus, now with Sigil 1.6.1's already-pushed fix, this 1 second will be buried out of the way.

[KevinH]

FYI, That fix will probably appear in a 1.7.0 release after a few new features have been added. As for timings, 0.9.14 only searches for a word, not the word and language, so it will be much faster as it does not require any code parsing at all. Sigil, unlike calibre (unless Kovid changed it recently) only finds that word in the specified language so if a common misspelling exists in multiple languages it will just find the one matching the specific language being searched for. So the timings are actually not comparable since they do different things.

Once 1.7.0 is released in a few months (or if people build their own from master) if others see the same timing issues with your test case (that I can not reproduce under macOS) we can revisit things to see if something platform specific is at issue.

[BeckyEbook]

I would like to comment on the problem reported by @Turtle91 here.

- If you are finding some text and it switches to a new html page the code view will show the correct location with the found text highlighted, but the preview window just displays the top of the new html page. It appears to go to the correct location if the found phrase is on the same html page.

During pre-1.6.0, released 1.6.0 and current pre-1.6.1 tests (I always have the current private build from master) I noticed this problem many times, but I did not consider Sigil to be guilty, but my old computer (i5-2500K, 16GB).

However, last week I finally bought new equipment (i7-11700, 32GB) and I still have the mentioned problem (Windows 10 Pro).
This is exactly step-by-step:
* I'm opening a new EPUB file.
* I search for a word (the XHTML file with the first finding is opened in a new tab).
* In the Preview window I can see the beginning of the file, although the found word is highlighted in Code View in the middle of the file, far from the beginning of the file.
* If I search for the next word and it appears in the same XHTML file, the Preview window will show the correct place, but if it requires opening a different XHTML file in a new tab, the problem will appear again.

(This is the same situation described by @Turtle91.)

Perhaps this is Windows-only related?

[KevinH]

That should be fixed in master. Please try opening a CV tab, clicking on a word to sync to Preview, next open any css tab, then switch back to the html tab you had opened. You should see the word you clicked on and Preview should have properly synced.

That bug (also reported by Turtle91) fix seemed to fix Preview syncing to CV either via click or via sync to search. At least it does for macOS.

Can you reproduce that part of his bug report in current master as well?

[BeckyEbook]

Originally Posted by KevinH

That should be fixed in master. Are you testing with Sigil-1.6.0 or master?

Yes.
Especially just a moment ago, I made a fresh build from the master with the latest commits.
Issue exists.

EDIT: After clicking in the Code View window, it works OK.
Only searching (no clicking) does not work.
Of course, I can live with it if you confirm that this action is intentional.
This is strange because - as mentioned above - Find Next in the same XHTML file works fine and I don't need to click anything.

[KevinH]

I will try again to reproduce what you are seeing on macOS. But the earlier fix should correct both as it involves opening a new tab resource and having Preview sync to CodeView location in that new tab.

I just want to make sure your master build has that fix for the xhtml->css->xhtml tab sequence sync to Preview fix working.

[KevinH]

It is not intentional. The problem is that loading PV from CV and telling it to go to a specific location was working only 60% of the time due to timing issues with sequences of Qt signals.

I thought it was fixed, but I may be wrong.

[KevinH]

Just to help track this down, did this used to work in 1.5.1, 1.4.3 or 1.3.0?

[BeckyEbook]

Yes. I confirm, that xhtml->css->xhtml fix working.

[BeckyEbook]

Originally Posted by KevinH

Just to help track this down, did this used to work in 1.5.1, 1.4.3 or 1.3.0?

I will check previous versions and let you know.

[BeckyEbook]

1.5.1 – works.
1.4.3 – works.
1.3.0 – works.

[KevinH]

So, the async Preview Loading we just added seems to be the issue here.

From reading the code, all CV searches that find something should cause PV to sync, but CV is loading before the asynchronous Preview loading is complete and the scroll to the search location is getting ignored since PV is not fully loaded yet.

I will have to think about how to handle this since we have moved to asynchronous loading of PV.