Listing all links in a PDF document can take a long time

[David.P]

Hello Forum and Tracker Support Team,

for large PDF documents, especially those containing many internal links, displaying the links in the Links Pane can take quite a long time. For example, I have many documents where each document can contain thousands of internal links:

image.png

In this case, listing all links in the Links Pane can take several minutes. It seems that for listing the links, every time the text under the link (i.e. the link "Title") has to be read in again, which is time consuming.

If pages are then added to the document, for example, or pages are deleted from the document, then a large portion of the links are re-read each time, which again can take minutes.

Perhaps there is a way to store (or at least cache, as long as the document is not closed) all properties of a link, especially the location and the page text associated with each link, along with the link in the future?

This way, listing thousands of links in the Links Pane could then perhaps be as near-instant as listing thousands of comments in the Comments Pane, for example:

image.png

Thank you very much for consideration of this feature request.

Kind regards
David

[Stefan - PDF-XChange]

Hello David.P,

Thanks for the detailed post!
I've created a ticket in our system:
#5662: Editor: Links Pane speed improvements
So that we can work on improvements in the speed of this pane.

Kind regards,
Stefan

[David.P]

Thank you Stefan, for the fast action!

Looking forward for faster link pane display,

Best regards
David

[Paul - PDF-XChange]

[rakunavi]

Hello all,

Perhaps an option to hide the Title column might eliminate the bottleneck and allow the Links pane to be displayed in an instant.

In my case, most of the links in the Links pane have a blank Title column because I often set links outside of the base content text, such as comments. Therefore, by necessity, I distinguish each link with a Page or Action column and seldom refer to the Title column.

Therefore, if the bottleneck is primarily due to the time it takes to collect the information in the Title column corresponding to each link, then, at least for me, I am waiting in vain for information to appear that will never be used at all. If there are CPU resources used for that, it would be much more appreciated if the Named Destination of the GoTo/GoToR action were displayed instead.

Of course, if performance can be greatly improved through programming innovations while maintaining current functionality, that would be ideal. However, it is only an ideal, and I fear that we will not see any significant changes in many years to come. Also, no matter how long we wait, it may be difficult for the Links pane to be displayed in an instant like the Bookmarks pane.

Personally, I would be very grateful if an optional setting could be introduced to hide the Title column and not collect any Title information corresponding to each link, so that the Links pane could be displayed instantly.

Thank you for taking the time to read this message.

Best regards,
rakunavi

[Stefan - PDF-XChange]

Hello rakunavi,

Thanks for your post!
I've added your comments to the ticket and asked for any news or comments from the dev team on this.

Kind regards,
Stefan

[David.P]

Hello all,

I could also imagine that, as rakunavi suggested, the performance issues of the link pane are due to the need to populate its title column.

This requires checking the size and X/Y coordinates of the bounding box of each link to determine if there is any text within the same area, and then extracting that text. This process is likely algorithmically complex and time-consuming.

Therefore, rakunavi's suggestion to hide the title column (not even calculating its contents of course) probably could significantly improve the performance of the link pane.

Additionally or alternatively, as discussed earlier, implementing some form of caching, similar as with the text search functionality, could be beneficial. This would mean the link pane would only need to be populated during its initial creation. When then changes are made, such as creating or deleting links, the link pane would not have to be completely rebuilt each time.

Best regards
David

[Stefan - PDF-XChange]

Hello David.P,

Appreciate your comments as well!
I can only speculate at this moment why the links pane is so complex and time consuming to generate.
I've asked for this ticket to be raised in priority and our devs would likely mention what was the slowdown when they look into that ticket, and then I would be able to tell you what was the culprit

Kind regards,
Stefan

[rakunavi]

Hello all,

As I said before, the incredibly slow display of the link pane is probably due to the collection of base content text corresponding to the link area, so if we can disable the display of the text column, I expect that the link pane would then display all items in an instant.

The rationale for this is noted for reference. The lower the density of links present in the page, i.e., the fewer the number of links per page, the slower the display time per link. Conversely, the more links per page, the shorter the display time per link. For example, the time required to display all items in the links pane of an actual document can be measured as follows

• Total pages: 503, Total links: 5,500, Duration: 1 minute 38 seconds
• Total pages: 2,124, Total links: 3,380, Duration: 6 minutes 48 seconds

The Task Manager shows that PDF-XChange Editor uses only about 0.2% of CPU resources while creating the list in the links pane. It also does not access storage at all. This means that no matter how high-performance a PC you buy, you cannot expect to improve the display speed of the links pane, and this is my experience as well.

So, as an experiment, I measured the time it takes to display all the links in the links pane in the following two cases. In both cases, the total number of links is the same, with a total of 5000 links and 5000 total pages.

• (case A) one link per page.
  (case B) all links are set on page 1.

• SampleFiles.zip

The former is the slowest case and the latter is the fastest case. The video first creates a sample file for each case. Then, for each case, I open the file and observe the display speed when the links pane is opened.

• Animation.gif

In the video, the file is closed halfway through for the former case, but if you wait until the end, it takes 16 minutes and 58 seconds for all the links to appear in the links pane. In contrast, you can see that the latter can display all items almost instantly. At most, it would take less than a second at most. In other words, as a result of extremely increasing the number of links per page, the display time per link has become extremely short and finally instantaneous. This is just my personal estimation, but if the text columns could be disabled in the links pane, it should be as fast as this.

The text columns in the links pane have never been useful to me personally in all the years I have been using it. It is honestly tough to wait endlessly for useless data to be collected when there is work I want to do immediately in the links pane. Regardless of priority, this is probably the area where there is the most room for improvement in the PDF-XChange Editor.

Thank you for taking the time to read this message.

P.S.
In the video, when creating the sample file for Case B, after creating the links on page 1, the current page is changed to page 2 before the Duplicate command is executed. This is because if the current page is left as the first page, the CPU load will temporarily increase when 5000 links are displayed in the page view, so to avoid this, the current page is changed to the second page while keeping the links selected. Perhaps some of you may be curious about the intent of my operation, so I will add this just in case.

Best regards,
rakunavi

- PDF-XChange Editor PRO Version: 10.5.2 build 395
- OS Version: Windows 11 Pro / Home 24H2 Build 26100.3775
- PC Model: GMKtec Nucbox M7 Pro with HUION Kamvas Pro 19 / Lenovo IdeaPad C340-15IWL

[David.P]

Bravo! Dear PXE Team, please listen very carefully to Mr. Rakunavi's analysis and suggestions for improvements.

[Stefan - PDF-XChange]

Hello David.P, Rakunavi,

Actually it would seem like the speeds Rakunavi measured in the first part of his post are pretty consistent for number of pages per second - for the 503 page file and 98 seconds that gives ~5.13 pages per second processed, for the 2124 page file and 408 seconds the speed is ~5.20 pages per second - pretty consistent given that not all pages were with exactly the same content.

The 5000 links tests can't clearly measure the speed for the file with the 5000 links all on the same page, but the other test seems to also be doing about ~5 pages per second. (5000 pages - 1018 seconds).

There does seem to definitely be room for improvement (the 0.2% CPU usage with no noticeable disk usage either), so I will once again request that this is looked with higher priority!

Kind regards,
Stefan

[rakunavi]

Hello David.P, thank you for your comment!
And Stefan, I appreciate you reaching out to the developers.

In my last post, I reported that the "caseA.pdf" sample file, with one link per page for 5000 pages, took 16 minutes and 58 seconds to display the link pane all the way through in build 395. However, with the recently released build 396, it took only 1 minute and 42 seconds. Even though the title is still displayed in the pane, the display speed is 10 times faster. Still, with a CPU utilization of only 0.2%, it is as if almost no computer resources are being used, so there is still a lot of room for developers to show their skills.

I would like to thank the developers for their efforts in this improvement, and I hope that there will be more improvements to come.
I really love developers who make steady improvements like this, even if nothing is mentioned in the version history.

Please give my best regards to developers.

Best regards,
rakunavi

[Daniel - PDF-XChange]

Hello, rakunavi

I am glad to hear you are happy with the improvements so far. While there are indeed always improvements to be made, some level of "rate limit" is needed as a sort of safety restriction, we may try to increase this gradually over time, as processing power increases, but I cannot promise that CaseA will ever be "instant" like CaseB is.

Due to the nature of PDF having some pages which are considerably heavier than others, starting the process of loading these items from every single page at the same time could be detrimental. Following the recent example, instead of seeing the progress over time, you might in some cases see nothing at all happen in the links pane for the 1m42s, while it tries to fetch a list from all 5000 pages at once, before everything pops in at the end.

In a blank document like CaseA here, that would likely be a very fast process, but the situation is different when actual content is present. Even without title detection, some level of processing this content is required to locate all of the links. This is also why your CaseB file loads near instantly, since all links are on page 1, only that one page needs to be checked before the process is completed.

Kind regards,

[rakunavi]

Hello Daniel, I really appreciate your detailed and kind response.

Before build 396, the Links pane was so slow that I routinely used the Export to XFDF feature. If you just export to an XFDF file, the file is generated in an instant, without having to wait for the Links pane to finish displaying. Therefore, there were quite a few cases where it is faster to process it yourself.

For example, if you want to delete all the links from page 4001 to 5000 of the file shown in caseA.pdf, you do not need to write a program for that, but an editor that supports regular expressions will suffice. For reference, here is an example using Notepad++.

1. Export to XFDF file
2. Bulk replace with Notepad++
   • Find what: \t\t<link .+?page="4\d{3}"[\s\S]*?</link>\n
   • Replace with: <blank>
3. Select all links by Ctrl+A and delete by Delete key
4. Import from XFDF file

• Animation.gif

• caseA.pdf

Please note the reality that the work was completed in 36 seconds, which is significantly faster than displaying the Links pane all the way to the end, despite manual operation using available software that already exists. Even though build 396 is 10 times faster than before, if you waited for the Links pane to appear and did the same work, it would take at least 1 minute and 42 seconds. Before build 396, the difference would have been much larger.

• Bulk delete links that exist in a specific page range
• Bulk delete links that link to a specific file
• Bulk delete links to a specific page

It seems rather wasteful to have to wait for the Links pane containing text titles to be updated just to do these tasks and others.

I have written about this at length, but the previous nightmare situation is much improved with build 396. For me, it is common for the number of links to exceed 5000, but for many users, it may not be so common. In that case, many users will be happy enough with the current behavior.

In any case, I believe that a deep understanding of the user's actual use case and the effective processing of the appropriate information is a very important part of program development.

Thank you for taking the time to read this message.

Best regards,
rakunavi

- PDF-XChange Editor PRO Version: 10.6.0 build 396
- Notepad++ v8.8.1 (64-bit)
- OS Version: Windows 11 Pro / Home 24H2 Build 26100.3775
- PC Model: GMKtec Nucbox M7 Pro with HUION Kamvas Pro 19 / Lenovo IdeaPad C340-15IWL

[David.P]

Hello all,

this observation by @rakunavi is very interesting, and strongly suggests that populating the link pane could be significantly faster even than it is now, since PDF-XChange Editor is evidently already capable of generating most or all necessary link data instantly -- as demonstrated by the Export to XFDF feature.

Before build 396, the Links pane was so slow that I routinely used the Export to XFDF feature. If you just export to an XFDF file, the file is generated in an instant, without having to wait for the Links pane to finish displaying.

Keep up the great work!

Best regards,
David

[Daniel - PDF-XChange]

Hello, David.P

As always, we do work to improve these features over time, but I am afraid that I cannot offer any further information on this topic currently.

Kind regards,