Quote:
Originally Posted by DiapDealer
EDIT: Just to clarify, this is in no way new to Sigil 1.5.1.
|
Yep, definitely. The issues I brought up have been lurking in Sigil for all the years I've been using it.
I just learned to completely avoid monolithic HTML files + kept Preview closed by default... and now continue to do so out of habit.
(Preview + Sigil overall has gotten
much faster/better though.
)
Quote:
Originally Posted by DiapDealer
Many of them I would expect, but the UI interface freezing in general (after the merge is done) seem odd to me (as well as unique unique to Windows, in my experience).
[...] During that time, processor/ram/disk/gpu usage was not particularly high (both cumulatively--for all processes--and for Sigil specifically). One notable thing is that the Windows 10 task manager indicates that power consumption is "very high" during the merge process. [...]
During the unresponsive periods, Sigil's processor and memory usage spike a bit (but nothing drastic, and not nearly enough to interfere with the running of other applications) and the power consumption indicator immediately spikes to "very high". The gpu % never moves from 0% for Sigil during any of my testing.
|
Hmmm.... interesting observation. I didn't think to have Task Manager and that column open at the time.
But that "Very High" makes me think... perhaps the laptop saw that, was in power-saving mode, then decided to aggressively throttle Sigil extra hard to "save battery"?
More Testing
During/after the merge, Calibre had a few "calibre worker processes" sitting in Task Manager:
- Calibre only jumped to "Very High" for a split second while generating the preview, then sat at "High" for ~6 seconds.
- ~1.5 cores + ~20% GPU usage
- (Calibre was using "~20% CPU". Since I have 8 cores: 1 core = 12.5%.)
- While syntax highlighting and everything else, it sat at "Medium".
- ~1/2 a core + ~5% GPU usage.
- Full-speed and usable this entire time.
- When everything was completed, dropped down to "Very Low".
Sigil, during these similar steps, used a full core the entire time (~13-15%).
When it finally settled down, and became clickable/scrollable... If I left to do something else for a minute, then clicked back into Sigil... it froze and jumped back to a full core for a while.
Quote:
Originally Posted by KevinH
As for the time to delete the now merged resources, it takes a long time because it requires parsing the opf, updating the manifest, spine, guide, and any nav landmarks (so parsing and recreating the nav each time too), then rebuilding the opf and saving it each time repeated for over 100 resources.
|
If you need a test EPUB for merging lots of internal links, this may also be a good one:
https://mises.org/library/man-econom...wer-and-market
That was a 1500 page book (each page is marked with an <a id="page_XXX"></a>) with ~6000 links in the Index.
(That's the only one I remember off the top of my head where the Index was >300KBs so had to be split. I definitely know I've worked on multiple books with even larger Indexes though, but I don't recall which ones.)
Quote:
Originally Posted by KevinH
Only the merge case would require deleting so many resources at once, so it was designed for single use and safety not speed. I will look into adding a bulk removal routine to save some time.
|
And Calibre has this nice menu selection where you pick WHICH file you want to merge into:
