PERFORMANCE: 4.5 Beta 12: Navigating via TOC through PB's is awfully slow

Open a PB with a good amount of text and number of chapters, a standard book-length one.

Open the TOC.

Click on one chapter heading after another to navigate through the text.

On my super-fast computer it takes about 3 seconds for the window to scroll to the correct position. It should be virtually instantaneous.

If you need logs and a sample PB in order to reproduce and troubleshoot this, I can provide them.

Find more posts tagged with

Comments

Bohuslav Wojnar

Rosie, I try to reproduce the problem and it works differently for me. When I open PB, it gets to the location almost instantaneously. I have Beta 12 installed and I have opened a couple of PB books and it works correctly. I have no idea what might cause the problem in your case.

P.S. I have 4 years old Dell notebook.

Rosie Perera

https://community.logos.com/discussion/comment/320094#Comment_320094

OK, here is a log file and PB. I'm not positive about the copyright status of this, though (see discussion on this thread). So consider it only for bug reproduction needs.

8422.Logos4.log

2727.Nicomachean Ethics (English).docx

Bohuslav Wojnar

https://community.logos.com/discussion/comment/320095#Comment_320095

I tried your book and compared it with one of my bigger books (Systematic Theology) and I have to say that my PB is faster (almost instantaneous) compared to one or 2 seconds of your PB. I have no idea about the reasons.

toughski

https://community.logos.com/discussion/comment/320108#Comment_320108

Rosie,

I tried to build your book and succeeded on the 5th try. Switching from "Chapter" to chapter takes 2-6 seconds on my Intel i7, 8GB RAM, Win7, SSD machine. I actually don't have a beta on this machine, so it probably NOT a beta issue. Something is definitely giving fits to the parser and PB display engine.

I once had a notepad replacement program that could display all of the "extra" codes that Word puts in, but I can't find it right now. Let me try something else and I will get back with you.

toughski

https://community.logos.com/discussion/comment/320146#Comment_320146

Rosie,

I completely rebuilt .docx file from plain text, added "Chapters." First build did not complete. Second build took 5+ minutes, but resulted in a PB - same performance as before - 2-6 seconds delays in jumping from chapter to chapter.

Must be the compiler/display engine. Could be WPF (I wish Logos got rid of that, but I am afraid it's out of the question)

DMB

https://community.logos.com/discussion/comment/320150#Comment_320150

Can't speak to the PB but the behavior also shows up in some of the regular resources (most notably the english translation of the Peshitta; larger chapters). I had assumed it had to do with paging inside the file itself.

Mark Barnes

https://community.logos.com/discussion/comment/320152#Comment_320152

Can't speak to the PB but the behavior also shows up in some of the regular resources (most notably the english translation of the Peshitta; larger chapters). I had assumed it had to do with paging inside the file itself.

It happens in very long 'articles' (i.e. where there is a very large gap between TOC headings). Adding sub-headings would solve the problem, I think.

toughski

https://community.logos.com/discussion/comment/320165#Comment_320165

I added subheadings and the book indeed became more responsive. Is that the same experience for you, Rosie

Mark Barnes

https://community.logos.com/discussion/comment/320150#Comment_320150

Must be the compiler/display engine. Could be WPF (I wish Logos got rid of that, but I am afraid it's out of the question

It's to do with positioning the text in the right place, complete with visual filters. If all visual filters are turned off, then performance improves. I surmise that when Logos calculates the current position in a text, it does so in relationship to the beginning of that section. Long sections therefore cause delays, which normally wouldn't be noticed. But very long sections cause very long delays, particularly if visual filters are being applied.

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/320295#Comment_320295

Long sections therefore cause delays, which normally wouldn't be noticed. But very long sections cause very long delays, particularly if visual filters are being applied.

We plan to improve the speed of resource display for very long articles in a future release. Until then, you can help the system out by breaking your articles down into smaller chunks. For this resource, I would strongly recommend inserting second-level headings for each of the chapters in each book.

Rosie Perera

https://community.logos.com/discussion/comment/320305#Comment_320305

Long sections therefore cause delays, which normally wouldn't be noticed. But very long sections cause very long delays, particularly if visual filters are being applied.

We plan to improve the speed of resource display for very long articles in a future release. Until then, you can help the system out by breaking your articles down into smaller chunks. For this resource, I would strongly recommend inserting second-level headings for each of the chapters in each book.

No, I'm not planning on it. I don't need the TOC cluttered with all the sub-sections. And if I work around this performance problem there won't be as much incentive for you guys to actually fix it because nobody will be griping about it anymore. [;)]

DominicM

https://community.logos.com/discussion/comment/320322#Comment_320322

@ ROsie LOL

@ Bradley, look forward to the promnised speed improvements in future